home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / isis / 369 < prev    next >
Encoding:
Text File  |  1993-01-09  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!think.com!rpi!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: Re: spooler usage
  5. Message-ID: <1993Jan9.140019.23960@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. References: <QfHZ0bu00hNP9DzF9=@cs.cmu.edu>
  8. Date: Sat, 9 Jan 1993 14:00:19 GMT
  9. Lines: 38
  10.  
  11. In article <QfHZ0bu00hNP9DzF9=@cs.cmu.edu> Sean.Levy@cs.cmu.edu writes:
  12. >I have a very simple question about the use of the spooler. After having
  13. >read the spool(3) man page, one thing is not clear to me: what does a
  14. >reply() call do when given a message that came (either via play-back or
  15. >play-through) from the spooler?
  16.  
  17. I'll have a look at the code, but I think the reply would go back to
  18. the spooler where it would be discarded.  The real point is that
  19. since the sender is not waiting for replies, having called spool
  20. to send the message rather than bcast, even if it went back to the
  21. sender the sender would ignore the reply.
  22.  
  23. So, you'll want to make a table of pending operations.  When you send
  24. to someone over your slow line, also add a new pending op entry to the
  25. table and include a reference to it in the message.
  26.  
  27. Implement a reply "manually" by spooling a message back in the other
  28. direction that includes the op reference explicitly.  Pair them up,
  29. and you have essentially done what collect-replies does now (except
  30. that your version won't handle nullreply, abortreply, multiple replies
  31. from a group, or failures :-( )  This is what we meant by a "call back"
  32. style in the documentation.
  33.  
  34. The problem is that leaving a task waiting for hours or days just
  35. doesn't make a lot of sense, and the basic scheme for replies keeps
  36. a task around.  Long delays associated with spooler interactions to
  37. infrequently run servers or to the WAN code just don't match with
  38. a synchronous request-reply style of coding.  We originally thought 
  39. about doing it in a more transparent way, but ended up with this
  40. instead.
  41.  
  42. In Horus, which will focus more on news, we may have another look
  43. at this whole issue...
  44.  
  45. -- 
  46. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  47. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  48. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  49.