home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / softsys / andrew / 1370 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.3 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!uwm.edu!linac!att!ucbvax!TRANSARC.COM!Craig_Everhart
  2. From: Craig_Everhart@TRANSARC.COM
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Re: Question about AMDS message delivery
  5. Message-ID: <Mf200tf0BwwS8qI0tP@transarc.com>
  6. Date: 16 Nov 92 20:10:33 GMT
  7. References: <1992Nov13.184644.19701@alw.nih.gov>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Distribution: world
  10. Organization: The Internet
  11. Lines: 63
  12.  
  13. Excerpts from internet.other.info-andrew: 13-Nov-92 Question about AMDS
  14. message.. Neil Weisenfeld@ucbvax.B (1023)
  15.  
  16. > Our AMDS system is set up so that a number of machines may deliver the
  17. > same message.  Is there any sort of locking system used to keep them
  18. > from stepping on each other's toes?   I'm writing a biff program and it
  19. > seems to suffer from two ailments:
  20.  
  21. > 1. Sometimes the user gets informed about a message twice since its
  22. > modification time changes twice.
  23.  
  24. > 2. Sometimes the biff program starts scanning the message for headers
  25. > as the message is being written and subsequently winds up hitting EOF
  26. > before finding all of the headers.
  27.  
  28.  
  29. > Now I know that I could solve #1 by keying off of the filename and not
  30. > checking the same file twice, but how about #2?  Is there some lock
  31. > mechanism for the Mailbox directory or the message files, or is it just 
  32. > a free for all?
  33.  
  34. Sure, there's a locking mechanism.  You can solve both problems by using it.
  35.  
  36. The delivery protocol for new messages being created in ~userid/Mailbox/
  37. is as follows.  The delivery agent (the producer) follows one protocol,
  38. and the reader (the consumer) follows another.
  39.  
  40. Delivery agent/producer:
  41.     (d1) invent a filename (generally with an ams_genid() call); call it FOO
  42.     (d2) create ~userid/Mailbox/FOO with open(), getting a file
  43.     descriptor (``fd'')
  44.     (d3) flock(fd) with an exclusive lock.
  45.         -- on failure, close the file, leaving a zero-length file;
  46.         restart at step (d1), creating a new file name.
  47.     (d4) write the contents of the file
  48.     (d5) close the file, releasing the lock in the process.
  49.  
  50. Reader/consumer:
  51. For each file in the ~/Mailbox directory (here named FOO):
  52.     (r1) open the ~/Mailbox/FOO file with open(), getting a file
  53.     descriptor (``fd'')
  54.     (r2) flock(fd) with an exclusive lock.
  55.         -- on failure, close the file and skip processing FOO.
  56.     (r3) get file status with fstat(fd) or whatever, to check the file
  57.     length and age.
  58.         -- if zero-length and under 20 minutes old, close the file and
  59.         skip processing FOO.
  60.         -- else if zero-length, ignore it as an orphan.
  61.     (r4) read the file and unlink it from ~/Mailbox when done.
  62.  
  63. At at least one point I believed that this would be an adequate
  64. interlock model.  The down-side is that if (r1+r2) interleaves between
  65. (d2) and (d3), the delivery process leaves an orphaned zero-length file
  66. that has to be reaped somehow; hence the heuristic measure as the last
  67. clause of (r3).
  68.  
  69. An amds-biff process would be excellent, and could simply follow the
  70. same protocol as does the reader, except for unlinking the file in step
  71. (r4).  I'd argue that both your problems arise when your biff checks new
  72. files between (d2) and (d4), and that you can dodge the problem with the
  73. flock() protocol.
  74.  
  75.         Craig
  76.