Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!liam
From: liam@cs.qmw.ac.uk (William Roberts)
Newsgroups: comp.protocols.nfs
Subject: Re: Mountd loops in case of multiple mount requests.
Message-ID: <2285@sequent.cs.qmw.ac.uk>
Date: 29 May 90 09:18:58 GMT
References: <2143@inews.intel.com> <4290@hcx1.SSD.CSD.HARRIS.COM>
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 29

In <4290@hcx1.SSD.CSD.HARRIS.COM> cliff@SSD.CSD.HARRIS.COM (Cliff Van Dyke) writes:

>In general the algorithms used for the UDP version of RPC in the
>applications (e.g., ypserv and mounted) and the kernel (e.g., NFS and
>lockd) leave much to be desired. I suspect some mechanism which uses
>the history of previous performance of a server would prove to be most
>beneficial.

The reason that the kernel stuff survives whereas the
application stuff dies is that ther user stuff is implemented
with the assumption that calls are non-idempotent (even if the
application writer knows full well that they are!).

Individual yp lookups would be happily served by allowing an
idempotent request option: instead of waiting longer each time
before retrying until eventually you give the server enough
time, you could also accept the first answer you get even if it
is beyond the timeout (this is what the kernel does for NFS
requests, for example). By all means make timeouts adaptive to
server load, but why waste good replies?

Does anyone know why the standard libraries make stream
connections to the portmapper?
-- 

William Roberts                 ARPA: liam@cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam@qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  071-975 5250 (Fax: 081-980 6533)