Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Jul 1997 12:12:28 +0200
From:      Sebastian Lederer <lederer@bonn-online.com>
To:        Terry Lambert <terry@lambert.org>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: NFS locking, was: Re: NFS V3 is it stable?
Message-ID:  <33BB7B0C.41C67EA6@bonn-online.com>
References:  <199707022052.NAA08047@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:

> 
> How do you think NFS server to NFS client responses operate?  The
> NFS client has to do the same types of things.

No,it does not. That's exactly the point.

The nfs client does a rpc call (e.g. NFSPROC_READ) to the nfs rpc
service on the nfs server, and gets an ordinary rpc reply as a result.

The locking client does a rpc call to the nlockmgr rpc service on the
nfs server (e.g. NLM_LOCK_MSG). No rpc reply is sent back.
The result of the locking operation is then sent as an entirely
different
rpc call from the nfs server to the nlockmgr service on the nfs client
(NLM_LOCK_RES).

That is, for the moment the nfs client becomes a server for the
nlockmgr service, and the rpc.lockd becomes the rpc client.

So there MUST be a rpc.lockd running on the nfs client
to gather these result messages. And this cannot be done in the kernel
because the nlockmgr service must provide the service for
both sides of the locking protocol simultaneously.
There is only one service with functions for both sides of the
protocol. And since rpc.lockd does provide the nlockmgr service, it
has to run on the server and the client.

If you don't believe me,
please take a look at /usr/include/rpcsvc/nlm_prot.x and
Andrew's rpc.lockd code. It handles the protocol the way I described it.

Best regards,

Sebastian Lederer

-- 
Sebastian Lederer
lederer@bonn-online.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33BB7B0C.41C67EA6>