Is there any variable or such I can check in my Server Module that would allow me to detect if the connection is still established? Also if I try to send_data and the connection is not established anymore will that just be silently ignored ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/9afd1103/attachment.html
On 3/4/07, Daniel Aquino <mr.danielaquino at gmail.com> wrote:> Is there any variable or such I can check in my Server Module that would > allow me to detect if the connection is still established? > Also if I try to send_data and the connection is not established anymore > will that just be silently ignored ?class FooServer < EventMachine::Connection def connection_completed @connection_status = true end def unbind # we are here, because connection was lost @connection_status = false end def main_handler reconnect(@ip, at port) unless @connection_status send_data("some crap\n") if @connection_status end And I guess if connection is lost and you are trying to call send_data, you should get a exception tossed. -- gnufied ----------- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. http://people.inxsasia.com/~hemant
On 3/4/07, Daniel Aquino <mr.danielaquino at gmail.com> wrote:> Is there any variable or such I can check in my Server Module that would > allow me to detect if the connection is still established? > Also if I try to send_data and the connection is not established anymore > will that just be silently ignored ?If the connection gets disconnected, unbind() will be called. If unbind() is called, don''t call send_data anymore. You can set a flag in your protocol handler when unbind is called if you need to check it later. I am looking at the C++, and I don''t see where an exception is thrown if send_data is called after the connection is closed. Francis, am I missing something, or does it just return silently? Kirk Haines
On 3/4/07, Kirk Haines <wyhaines at gmail.com> wrote:> > If the connection gets disconnected, unbind() will be called. If > unbind() is called, don''t call send_data anymore. You can set a flag > in your protocol handler when unbind is called if you need to check it > later. > > I am looking at the C++, and I don''t see where an exception is thrown > if send_data is called after the connection is closed. Francis, am I > missing something, or does it just return silently?This is really somewhat challenging because there are a lot of ways to fail when you write data to a socket, and not all of them produce clear-cut errors. A cable-cut, for example, is brutal because what you''ll get is a slowly filled-up outbound kernel buffer, or a closed TCP window. The application might never find out unless you time out waiting for some application-level response. Other scenarios (like receiving a CONNRESET from the remote peer) will behave differently depending on the routing infrastructure between you and the remote peer. I just thought it would be better not to throw any errors at all than to nondeterministically throw them sometimes and not other times. Look at Connection#set_inactivity_timeout for one way to manage busted connections when you need to be sure. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/7ba9f8d9/attachment.html
On 3/4/07, Kirk Haines <wyhaines at gmail.com> wrote:> > > I am looking at the C++, and I don''t see where an exception is thrown > if send_data is called after the connection is closed. Francis, am I > missing something, or does it just return silently?Almost forgot one important point. If send_data ever produces a recognizable socket-level error (other than EAGAIN, which is buffered internally by EM), it *will* close the socket, and #unbind will get called. So Kirk, your original answer was correct. #unbind is the way to manage the situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/193a5288/attachment.html
Well Hemant what is "connection_completed" I currently use "post_init"... And basically I''m using post_init and unbind to call hooks in application code for initial and cleanup actions... So in my application code I have a wrapper for send_data that I use... Basically If my "cleanup" hook is called by my "unbind" code the connection will be closed! So I wanted to see if in my send_data wrapper I could do some type of test on the EM Server Module instance, that would allow me to detect that the connection is down and silently not send any data. Sorry if I''m asking the same question twice here... Just trying to clarify my question just in case.. On 3/4/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 3/4/07, Kirk Haines <wyhaines at gmail.com> wrote: > > > > If the connection gets disconnected, unbind() will be called. If > > unbind() is called, don''t call send_data anymore. You can set a flag > > in your protocol handler when unbind is called if you need to check it > > later. > > > > I am looking at the C++, and I don''t see where an exception is thrown > > if send_data is called after the connection is closed. Francis, am I > > missing something, or does it just return silently? > > > > This is really somewhat challenging because there are a lot of ways to > fail when you write data to a socket, and not all of them produce clear-cut > errors. A cable-cut, for example, is brutal because what you''ll get is a > slowly filled-up outbound kernel buffer, or a closed TCP window. The > application might never find out unless you time out waiting for some > application-level response. Other scenarios (like receiving a CONNRESET from > the remote peer) will behave differently depending on the routing > infrastructure between you and the remote peer. I just thought it would be > better not to throw any errors at all than to nondeterministically throw > them sometimes and not other times. > > Look at Connection#set_inactivity_timeout for one way to manage busted > connections when you need to be sure. > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/59b5c166/attachment-0001.html
On 3/4/07, Daniel Aquino <mr.danielaquino at gmail.com> wrote:> > Well Hemant what is "connection_completed" I currently use "post_init"... > > And basically I''m using post_init and unbind to call hooks in application > code for initial and cleanup actions... > > So in my application code I have a wrapper for send_data that I use... > > Basically If my "cleanup" hook is called by my "unbind" code the > connection will be closed! > > So I wanted to see if in my send_data wrapper I could do some type of test > on the EM Server Module instance, > that would allow me to detect that the connection is down and silently not > send any data. > > Sorry if I''m asking the same question twice here... > Just trying to clarify my question just in case..Well, let''s see, if you call send_data to a dead connection, then EM will recognize that (because the socket write will fail) and it will close the connection and call #unbind. If you send data to a hung connection, there''s no way for EM to tell you that (because the kernel doesn''t know either). Fortunately that doesn''t happen often, and if you''re really worried about it, you can use an inactivity timer. EventMachine::Connection#connection_completed is called when you initiate a connection to a remote server. In such a case, #post_init is called after the TCP connect is initiated. But like everything else in EM, a TCP connect is nonblocking, so EM doesn''t know the disposition of the connect-attempt when it called #post_init. It then tries to do other work while waiting for the remote peer to respond. Hence the usefulness of a separate callback to tell you the remote server accepted your connection. If you get #unbind without getting #connection_completed, you can infer a refused connection or some other error. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/81e22d20/attachment-0001.html
Ok so your saying that post_init is after a tcp connection has been initiated... But connection_completed is fired when a connection has successfully been accepted by the remote party? Also I''m not particularly "worried" about the connection being down... I just want to make sure EM wont blow my program up if I try to send data and the connection becomes lost... If I''m correct I think I remember you saying that the data would just get buffered... Then once the connection has been lost completely the buffer is cleared? As long as my program doesn''t crash or something I''m happy... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070305/d67367a2/attachment-0001.html
On 3/5/07, Daniel Aquino <mr.danielaquino at gmail.com> wrote:> > Ok so your saying that post_init is after a tcp connection has been > initiated... But connection_completed is fired when a connection has > successfully been accepted by the remote party?Yes. Also I''m not particularly "worried" about the connection being down... I> just want to make sure EM wont blow my program up if I try to send data and > the connection becomes lost... If I''m correct I think I remember you saying > that the data would just get buffered... Then once the connection has been > lost completely the buffer is cleared? As long as my program doesn''t crash > or something I''m happy...Avoiding a crash in a program that could be handling thousands of connections is exactly what I had in mind when I decided not to throw exceptions on socket errors. EM will throw away all of the buffered data associated with either side of the connection when it closes the socket. The socket and its associated data structures are gone by the time #unbind gets called, so you can''t read or write that particular connection in an #unbind handler. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070305/9b60f450/attachment.html