 |
 |
On Fri, 4 Mar 2011, Lukasz Janyst wrote: > OK, then. I will fix the bug in ROOT, the one pointed out by Fabrizio, > add the setsockopt flags to support linux builtin keepalive, and in > longer term work on something for simulating keepalive with kXR_ping. We may want to make the "ping" mechanism selectable via an option of some kind. Just a thought. Andy > Lukasz > > 2011/3/3 Andrew Hanushevsky <[log in to unmask]>: >> Hi Lukasz, >> >> The client is always free to send a keep-alive to the server (a.k.a. >> kXR_ping request). The timeout for that can be set very short since the >> response occurs at the top-most layer in the server and turn-around should >> be in the microsecond range + RTT. That will tell you if the connection is >> alive. The server can send a ping to the client as well. But neither of >> these actions will solve many router issues. That's why you need reasonable >> timeouts. For instance (and why server-side pings are not all that useful), >> a server-side ping will do little if the router already broke the >> connection. Yes, the server-side connection *might* get closed but the >> client will never know that. >> >> So, to better address the problem I would proceed as follows: >> a) If you find out that a request has not been serviced in the normal >> time-out window, >> b) Issue a ping with a much shorter timeout. >> c) If you don't get a response at that point, tear down the connection and >> try again. >> >> For optimization purposes, I would keep track of the time between >> reconnections. That should provide a window (eventually) of when you must >> send a ping to keep the dumb router from dropping the connection. >> >> Andy >> >> -----Original Message----- From: Lukasz Janyst >> Sent: Thursday, March 03, 2011 3:32 AM >> To: Fabrizio Furano >> Cc: Lukasz Janyst ; [log in to unmask] ; Gerardo Ganis ; Brian Bockelman >> ; Andrew Hanushevsky ; [log in to unmask] ; [log in to unmask] ; Dirk >> Duellmann ; [log in to unmask] ; [log in to unmask] >> Subject: Re: [sr #119348] Root reports an error while unzipping the buckets >> fetched via xroot >> >> Hi Fabrizio, >> >> thanks for the info. As I say later in my comment, this would >> indeed help, in the sense that the client would get the response >> eventually, instead of hanging or crashing, but wouldn't eliminate the >> real problem: how to handle misbehaving networks. >> >> Cheers, >> Lukasz >> >> 2011/3/3 Fabrizio Furano <[log in to unmask]>: >>> >>> Hi Lukasz, >>> >>> something is fishy here: >>> >>>> Of course, on every request timeout I could assume that the connection is >>>> just broken even though the socket is in a valid state and reconnect, no >>>> problem about that. >>> >>> ... in the sense that this is supposed to be the default, normal >>> behavior. >>> On every request timeout the connection must be considered broken, and >>> completely wiped out. If it does not do it, then this is the issue to >>> consider first, imo. >>> >>> Fabrizio >>> >>> >> >> >