 |
 |
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. 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 >> >> > >