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

[Richard B. Johnson]

On 14 Nov 2002, Trond Myklebust wrote:

> >>>>> " " == Richard B Johnson <[e-mail]> writes:
> 
>      > 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.
> 
> Huh??? There's no 'application level' involved here at all, nor any
> 'internal TCP/IP code'.
> 
> Chuck's patch touches the way the kernel Sun RPC client code (as used
> exclusively by the kernel NFS client and the kernel NLM client)
> handles the generic case of message timeout + resend. Why would we
> want to even consider pushing that sort of thing down into the NFS
> code itself?
> 
> Cheers,
>   Trond
> 

Because all of the RPC stuff was, initially, user-mode code. For
performance reasons or otherwise, it was moved into the kernel.
Okay, so far? Now, when something goes wrong with that code, should
that code be fixed, or should the unrelated TCP/IP code be modified
to accommodate? I think the time-outs should be put at the correct
places and not added to generic network code.

Once the client side gets a buffer of data from the TCP/IP stack,
the TCP/IP should not care (ever) what it does with it. Putting
the timeout(s) in the TCP/IP stack, makes it care, and adds code
to accommodate.

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