home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1914 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.7 KB
  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!seven-up.East.Sun.COM!tyger.Eng.Sun.COM!geoff
  2. From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: lockd
  5. Date: 21 Jul 1992 19:46:10 GMT
  6. Organization: SunSelect
  7. Lines: 57
  8. Message-ID: <14hpi3INNppo@seven-up.East.Sun.COM>
  9. References: <1992Jul21.174721.26888@nntpd.lkg.dec.com>
  10. NNTP-Posting-Host: tyger.east.sun.com
  11.  
  12. Quoth uresh@ovrbid.lkg.dec.com (Uresh Vahalia) (in <1992Jul21.174721.26888@nntpd.lkg.dec.com>):
  13. #
  14. #I have a few questions about the lockd protocol, which I am trying to
  15. #implement:
  16. #
  17. #1.  There seem to be 3 flavors of each request - eg. for the lock
  18. #request, there is 
  19. #    nlm_lock, nlm_lock_msg and nlm_lock_res.  Why?  What are the differences?
  20.  
  21. nlm_lock is synchronous: the client requests the lock, and the
  22. server replies with a definitive "granted" or "failed" response.
  23.  
  24. nlm_lock_msg and nlm_lock_res implement a call-back model. The client
  25. requests the lock with nlm_lock_msg. This RPC is ack'ed at once. The
  26. server then makes an nlm_lock_res call-back to the client indicating
  27. either that the lock has been granted or that the request is being
  28. processed. In the latter case, the server will eventually respond by
  29. making an nlm_granted RPC to the client.
  30.  
  31. Why? Because back in 1986 it wasn't practical to create a multithreaded
  32. lock manager.
  33.  
  34. #2.  What are the version 3 requests for (share, unshare, nm_lock and free_all?)
  35.  
  36. share, unshare:    DOS-compatible file sharing by PC clients.
  37. nm_lock, free_all: locking support for PCs which couldn't run status monitors.
  38. (Disclaimer: I'm the author of these.)
  39.  
  40. #3.  What is the function of the cookie argument in all the calls?
  41.  
  42. It allows the lock manager to match up corresponding asynchronous
  43. requests and callbacks.
  44.  
  45. #4.  What does the svid argument mean?
  46.  
  47. In the X/Open spec it was renamed "uppid - unique per-process ID". Think
  48. "pid".
  49.  
  50. #Can anyone point me to any document which gives me a high level description of
  51. #the protocol (besides just the uncommented spec?).
  52.  
  53. There's only one good description:
  54.  
  55. X/Open CAE Specifications: Protocols for X/O Interworking - XNFS.
  56.                          (ISBN 1 872630 10 3. Doc No. XO/CAE/91/030.)
  57.  
  58. This document is available directly from the X/Open Company. As the time of
  59. writing, the phone numbers were:
  60.    USA:    +1(415)323 7992 or +1(703)876 0044
  61.    Europe: +44 734 508311
  62.    Japan:  +81 3 3251 8321
  63.  
  64. --
  65. ---------------------------------------+--------------------------------------
  66.      Geoff Arnold, PC-NFS architect    | Thought for the day: If Unix had been
  67.       (geoff.arnold@East.Sun.COM)      | developed in England, we'd all be using
  68. SunSelect, a Sun Microsystems Business | BCPL (and migrating to BCPL++)...
  69.