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

[Richard B. Johnson]

On 13 Nov 2002, Trond Myklebust wrote:

> >>>>> " " == Richard B Johnson <[e-mail]> writes:
> 
>      > 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.
> 
> An NFS server is perfectly free to drop an RPC request if it doesn't
> have the necessary free resources to service it (i.e. if it is out of
> memory). If the client doesn't time out + retry, you lose data. Not a
> good idea...
> 
> Cheers,
>   Trond

The Client is the guy that just retries, as you say from a time-out.
This shouldn't affect any internal TCP/IP code. The time-out is
at the application (client) level. It sent a request, the data
was sent or promised to be sent because the write() or send() didn't
block, now it expects to get the data it asked for. It waits, nothing
happens. It times-out and sends the exact same request again.

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