home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / programm / 5172 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  1.9 KB
  1. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!soda.berkeley.edu!achoi
  2. From: achoi@soda.berkeley.edu (Andrew Choi)
  3. Newsgroups: comp.unix.programmer
  4. Subject: How to Detect being fingered on NFS?
  5. Date: 5 Nov 1992 22:27:19 GMT
  6. Organization: U.C. Berkeley, CS Undergraduate Association
  7. Lines: 38
  8. Distribution: world
  9. Message-ID: <1dc747INNdcu@agate.berkeley.edu>
  10. NNTP-Posting-Host: soda.berkeley.edu
  11.  
  12. OK, this is not yet another "used a named pipe for your .plan"
  13. article, so, please don't jump into conclusion immediately.
  14.  
  15. Here's the problem.  I can be fingered at one of the serveral
  16. machines, i.e. "apple", "orange", "grape" ... etc. for the sake
  17. of argument.  Note that everything under my home directory is
  18. NFS-mounted (this includes my .plan).
  19.  
  20. If I have a process running on "apple" writing to my named pipe,
  21. it will detect if someone fingers me on "apple".  However, if
  22. someone fingers "orange", it will just hang forever because
  23. NFS does not really recognize named pipe and so the write from
  24. process at "apple" does not respond to a read from "orange".
  25.  
  26. There are several solutions to this problem:
  27.  
  28. 1)  Have processes running on all the machines, and have a
  29.     shared file recording the date and time I was fingered
  30.     so that all process can read and modify this file to update
  31.     change (this needs locking, of course).
  32.  
  33. 2)  Have a process which periodically checks the last access time
  34.     for my ".plan".  If the last access time has been changed,
  35.     assume that I am fingered and modify ".plan" accordingly.
  36.  
  37. The latter approach is the one I am using now.  I am just wondering
  38. if there is a better way to solve this problem that I don't see.
  39.  
  40. One of the problem with the last approach is that it won't be
  41. accurate, i.e., fingered several times between last check, and
  42. I don't want to make it check too frequently (like once a second)
  43. because that's too expensive.
  44.  
  45. Any ideas?  Anyway to have an accurate but yet non-polling approach?
  46.  
  47. -- Andrew Choi
  48.  
  49.  
  50.