how to handle socket timeout?
in [Unix Programming]
|
From: Arkadiy on 14 Jan 2008 21:05 On Jan 14, 5:25 pm, David Schwartz <dav...(a)webmaster.com> wrote: > > The question is then what timeouts should be used for? Only for > > detecting some abnormal situations, like server congested or server > > rebooted? What follows from the discussion seems to be that the usage > > of timeouts to limit the response time is not recommended, correct? > > I still think you are approaching this problem from the wrong > direction. You should follow the specifications for the protocol you > are implementing or the server you are talking to. If you have no such > specifications, you should do everything in your power to develop > some. The server protocol specifies: 1) That connections are reused between requests; 2) That client can close the connection anytime it no longer needs it; 3) Various request and response formats. That's it, to the best of my knowledge. Item 2 seems to imply that I am technically alowed to close the connection when the request times out. Whether or not it is a right thing to do due to performance reasons is a different story. By the way, here is the protocol: http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt > It sounds like you are using a protocol that is fundamentally broken > in that it provides no way to detect a truly abnormal situation. > Ideally, the protocol would be fixed. This is not up to me. > If you have no other choice, use a back off and retry model. Make sure > to back off a bit more (up to some reasonable cap) with each > successive failure. At least this way, if the server does get > overloaded, you will reduce the load on it and give it some hope of > recovering. What happens if the timeout was due to the server host got disconnected or something similar? Maybe I am wrong, but somehow this problem worries me more than the congestion issue... Regards, Arkadiy
From: David Schwartz on 15 Jan 2008 01:04 On Jan 14, 4:10 pm, Rick Jones <rick.jon...(a)hp.com> wrote: > The server's host rebooting will cause an RST to come back to the > client end in response to the first segment the client sends to the > server after it reboots because the server's host TCP will have no > knowledge of the connection. But since he's already sent his query and is just waiting for a reply, why should the client ever send a segment? > The RST arriving at the client should result in the socket becoming > readable and a read/recv against the socket returning EPIPE or > somesuch. If only his protocol were designed to ensure this would occur. DS
From: David Schwartz on 15 Jan 2008 01:08 On Jan 14, 6:05 pm, Arkadiy <vertl...(a)gmail.com> wrote: > What happens if the timeout was due to the server host got > disconnected or something similar? Maybe I am wrong, but somehow this > problem worries me more than the congestion issue... Set the timeout high enough so that timing out a working server is very unlikely. If necessary, use two timeouts, one to report failure and one to actually consider the operation to have failed. To probe, you can send a 'VERSION' command. This should cause your end to begin sending, ensuring that either the send will timeout or you will get a RST back if the connection is truly dead. You can really only probe reliably once though. It seems like if the server is unreachable, nothing you try will succeed anyway, so it doesn't matter particularly much what you do. DS
From: Arkadiy on 15 Jan 2008 09:50 On Jan 15, 1:08 am, David Schwartz <dav...(a)webmaster.com> wrote: > > What happens if the timeout was due to the server host got > > disconnected or something similar? Maybe I am wrong, but somehow this > > problem worries me more than the congestion issue... > > Set the timeout high enough so that timing out a working server is > very unlikely. If necessary, use two timeouts, one to report failure > and one to actually consider the operation to have failed. > > To probe, you can send a 'VERSION' command. This should cause your end > to begin sending, ensuring that either the send will timeout or you > will get a RST back if the connection is truly dead. Why do I have to use a 'VERSION' command to determine that the connection is dead rather than determine this based on the actual request? > It seems like if the server is unreachable, nothing you try will > succeed anyway, so it doesn't matter particularly much what you do. Does this mean 1) nothing sent will produce a response, so anything can be send to detect the condition, or 2) there is nothing we can do in the code to handle the situation? Regards, Arkadiy
From: Arkadiy on 15 Jan 2008 09:59
On Jan 14, 7:10 pm, Rick Jones <rick.jon...(a)hp.com> wrote: > Arkadiy <vertl...(a)gmail.com> wrote: > > However, what's bothering me, is how I tell the congested server > > from something like the server's host rebooted. In the later > > situation, I do want to reconnect. > > The server's host rebooting will cause an RST to come back to the > client end in response to the first segment the client sends to the > server after it reboots because the server's host TCP will have no > knowledge of the connection. This will take really long time. Also, what if the server host crached and never got rebooted? Or got disconnected? Regards, Arkadiy |