TCPSocket: how to realize that the other endpoint has closed the connection?

Hi, I open a TCP connection with a server:

socket = TCPSocket.new HOST, PORT

It’s connected. Later the server is stoped or restarted so the TCP
connection gets down. But if in the client I send data using
@socket.send” then it gets no error at all, it behaves as if the data
has been sent through the socket.

I expected that there should be some method to get the status of the
socket, but I cannot find it. Any suggestion please?

Thanks a lot.

2011/3/16 Iñaki Baz C. [email protected]:

It’s connected. Later the server is stoped or restarted so the TCP
connection gets down. But if in the client I send data using
@socket.send” then it gets no error at all, it behaves as if the data
has been sent through the socket.

However, if the client sends data again (using TCPSocket#send) then it
gets an exception. Why doesn’t such exception occur in the firs case?
it’s obvious that the connection has been closed by the other
endpoint.

Thanks,.

It’s possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.

If that doesn’t work, try sending a really long message the first time
and see what happens.

On Thu, Mar 17, 2011 at 3:38 AM, 7stud – [email protected]
wrote:

It’s possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.

Determining whether a network connection is still live is generally a
pretty complex thing. Usually the most reliable way to find out the
status of a connection is to use it. IIRC there are some socket
options that can influence shutdown behavior and timing. See for
example here for general description of socket options
http://linux.die.net/man/7/socket

and how to apply them
http://www.ruby-doc.org/stdlib/libdoc/socket/rdoc/classes/BasicSocket.html#M003703

Kind regards

robert

2011/3/17 7stud – [email protected]:

It’s possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.

Thanks, but I’ve added #flush before and after #send and it doesn’t
affect.

2011/3/17 Robert K. [email protected]:

On Thu, Mar 17, 2011 at 3:38 AM, 7stud – [email protected] wrote:

It’s possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.

Determining whether a network connection is still live is generally a
pretty complex thing.

Using EventMachine (to connect to a TCP server) the #unbind method is
inmediately called when the endpoint closes the connection.

Usually the most reliable way to find out the
status of a connection is to use it. IIRC there are some socket
options that can influence shutdown behavior and timing. See for
example here for general description of socket options
http://linux.die.net/man/7/socket

and how to apply them

http://www.ruby-doc.org/stdlib/libdoc/socket/rdoc/classes/BasicSocket.html#M003703

Ok, I’ll check such socket options.
Thanks a lot.

On Thu, Mar 17, 2011 at 12:06 PM, Iaki Baz C. [email protected]
wrote:

2011/3/17 Robert K. [email protected]:

On Thu, Mar 17, 2011 at 3:38 AM, 7stud – [email protected] wrote:

It’s possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.

Determining whether a network connection is still live is generally a
pretty complex thing.

Using EventMachine (to connect to a TCP server) the #unbind method is
inmediately called when the endpoint closes the connection.

No, it is immediately called when your local network stack determines
that the socket is closed. That is a hugely different thing! IP
networking is actually quite complex and behaves differently than,
say, an unnamed pipe between two local processes. “UNIX Network
Programming” by W. Richard Stevens used to be the standard book on the
matter; I guess today you’ll find such information on the web as well.

Thanks a lot.
YWC

Kind regards

robert

After the server closes its side of the socket, there must be some
amount of elapsed time after which if the client tries to send data over
the socket, the client will receive a broken pipe error. Is that 2.3
years? Or closer to five minutes?

Here is a very technical diagram that includes what happens when one
side closes the socket:

http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#ST

As far as I can tell, if the client sleep()'s long enough after the
server closes the socket, the client will receive a broken pipe error

On Fri, Mar 18, 2011 at 1:23 AM, Lou Z. [email protected] wrote:

This question comes up on the CocoaAsyncSocket list periodically. Robbie
Hanson’s post (the third one down), explains what is happening at the OS
level:

http://groups.google.com/group/cocoaasyncsocket/browse_thread/thread/8703a9ae74d5104f/a2297fe10c376c01

This one

http://groups.google.com/group/cocoaasyncsocket/msg/f3406580df083477

Not related to ruby, but it might help you understand what’s going on.

Yes, this is definitively a generic IP issue.

Kind regards

robert

This question comes up on the CocoaAsyncSocket list periodically.
Robbie
Hanson’s post (the third one down), explains what is happening at the OS
level:

http://groups.google.com/group/cocoaasyncsocket/browse_thread/thread/8703a9ae74d5104f/a2297fe10c376c01

Not related to ruby, but it might help you understand what’s going on.

Lou

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs