home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / isis / 247 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.7 KB  |  56 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!udel!rochester!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: Re: blocking requests
  5. Message-ID: <1992Sep15.203020.3360@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. References: <15353@borg.cs.unc.edu>
  8. Distribution: usa
  9. Date: Tue, 15 Sep 1992 20:30:20 GMT
  10. Lines: 44
  11.  
  12. In article <15353@borg.cs.unc.edu> krishnar@weiss.cs.unc.edu (Rajarama Krishnan) writes:
  13. >In my ISIS application a process has to join a process group. It has to get
  14. >some data from the group. I didnt put that in the state transfer routine
  15. >because I am also using logging and I dont want all this data to be passed
  16. >during logging. To get around problem, what I am doing is join the group and
  17. >then get the data separately. But this causes a problem. I start getting
  18. >requests even before I have transferred this data. How can I avoid this?
  19. >Is there anyway of blocking requests after the pg_join till I explicitly
  20. >allow the requests to come?
  21.  
  22. There is a subtle way to do what you want.  You should code your state
  23. transfer routine so that the receive routine in the process that is
  24. joining does an RPC to a process (or group) that has the data it wants
  25. from within the state receive routine.
  26.  
  27. The key thing is that it has to be inside the reception routine when it
  28. does the call.
  29.  
  30. At this stage of a computation, new requests are still blocked out, and
  31. they will remain blocked out in this case until the RPC finishes and
  32. hence the state reception routine finishes.  At least, I think that is
  33. what will happen.  
  34.  
  35. If this doesn't work, try initiating the operation from the send state
  36. routine in the process doing the transfer out.  E.g. the group sends
  37. a message into the new process "while state transfer is under way" that
  38. causes it to load the extra state.  I think this would work, too.
  39.  
  40. To avoid having the state logged, I think you just need it to show up
  41. as a reply to a message -- replies aren't logged.
  42.  
  43. A third approach would be to use isis_connect to make a TCP connection
  44. and send the data "out of band" over the TCP socket, during the join.
  45. Isis doesn't log data on TCP connections created this way.
  46.  
  47. All of these slip the data transfer in during the state transfer
  48. period, when you have requests blocked because the transfer is underway.
  49. In fact, what you are trying to do pushes a little beyond what the
  50. Isis join model can currently accomodate.  But, hopefully one of these
  51. tricks will work.
  52. -- 
  53. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  54. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  55. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  56.