re: [PATCH] new timeout behavior for RPC requests on TCP sockets

[Richard B. Johnson]

On 13 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-13 at 16:44, Richard B. Johnson wrote:
> > If the application "chooses to drop the request", the kernel is not
> > required to fix that application. The RPC cannot retransmit if
> > it has been shut-down or disconnected, which is about the only
> > way the application could "choose to drop the request". So something
> > doesn't smell right here.
> 
> Check your socks...
> 
> As far as RPC goes the RPC server can choose to drop a request whenever
> it pleases by simply throwing it away (eg reading it from the socket and
> binning it) depending on its workload. There are actually reasons for
> that in some situations (eg if the top requests are all for a volume
> that is down its better to throw them away so you can get requests for a
> volume that is functional)
> 
> Alan

Yes! But, the Client it is perfectly free to request it again and
should (must) to keep any mounted volumes intact. This doesn't
affect the internal TCP/IP stack (or it shouldn't). Since the whole
NFS thing is "stateless", the client just issues another request.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America