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.
--
Iñaki Baz Castillo
<ibc@aliax.net>
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,.
2011/3/16 Iñaki Baz Castillo <ibc@aliax.net>:
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ñaki Baz Castillo
<ibc@aliax.net>
It's possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.
--
Posted via http://www.ruby-forum.com/.
After the server closes its side of the socket, there must be some
amount of 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
--
Posted via http://www.ruby-forum.com/.
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
and how to apply them
http://www.ruby-doc.org/stdlib/libdoc/socket/rdoc/classes/BasicSocket.html#M003703
Kind regards
robert
On Thu, Mar 17, 2011 at 3:38 AM, 7stud -- <bbxx789_05ss@yahoo.com> wrote:
It's possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Thanks, but I've added #flush before and after #send and it doesn't affect.
2011/3/17 7stud -- <bbxx789_05ss@yahoo.com>:
It's possible that your first send() is stuck in a buffer. See if
calling flush() on the socket works.
--
Iñaki Baz Castillo
<ibc@aliax.net>
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:
Not related to ruby, but it might help you understand what's going on.
Lou
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/socketand 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.
2011/3/17 Robert Klemme <shortcutter@googlemail.com>:
On Thu, Mar 17, 2011 at 3:38 AM, 7stud -- <bbxx789_05ss@yahoo.com> wrote:
--
Iñaki Baz Castillo
<ibc@aliax.net>
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:
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
On Fri, Mar 18, 2011 at 1:23 AM, Lou Zell <lzell11@gmail.com> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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.
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/socketand how to apply them
http://www.ruby-doc.org/stdlib/libdoc/socket/rdoc/classes/BasicSocket.html#M003703Ok, I'll check such socket options.
Thanks a lot.
YWC
Kind regards
robert
On Thu, Mar 17, 2011 at 12:06 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/3/17 Robert Klemme <shortcutter@googlemail.com>:
On Thu, Mar 17, 2011 at 3:38 AM, 7stud -- <bbxx789_05ss@yahoo.com> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/