home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / isis / 234 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  4.3 KB
  1. Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!cornell!ken
  2. From: ken@cs.cornell.edu (Ken Birman)
  3. Newsgroups: comp.sys.isis
  4. Subject: Re: Process group addresses, DCE etc.
  5. Message-ID: <1992Sep2.162739.23713@cs.cornell.edu>
  6. Date: 2 Sep 92 16:27:39 GMT
  7. References: <barry.715250287@citr.uq.oz.au> <1992Aug31.185652.21586@cs.cornell.edu> <barry.715390460@citr.uq.oz.au>
  8. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  9. Lines: 75
  10.  
  11. In article <barry.715390460@citr.uq.oz.au> barry@citr.uq.oz.au (Barry Kitson) writes:
  12. >Hi,
  13. >
  14. >    Do all clients of a process group have the same address
  15. >for the group?  What I don't understand yet, is how virtual synchrony
  16. >is implemented, and what protocols operate between which objects.
  17. >How is ordering controlled in bcasts and who is responsible for
  18. >controlling it?
  19.  
  20. Isis implements protocols and a model described in two ACM TOCS papers,
  21. one in August 1991 and one in June 1987.  A prior ACM SIGOPS paper, also
  22. in 1987, describes the toolkit and the overall approach -- although TR1216
  23. will eventually be published and does a better job than the original 1987
  24. paper, I think.
  25.  
  26. To answer your questions, though: yes, all processes in the system that
  27. do a pg_lookup on a group (within the same LAN) get the same internal
  28. ISIS "address" back.  ISIS knows how to expand an address into the
  29. current membership of the group, but this information is only stored
  30. and updated at the members of the group, so anyone who isn't a member
  31. gets data that could be stale by the time it arrives.  We have a whole
  32. bunch of protocols engineered for different communication patterns and
  33. ordering properties, and you should read the papers if this interests you.
  34. Note, however, that the new ISIS system will actually be implemented
  35. entirely over cbcast and a type of "flushed" cbcast that achieves
  36. the properties of gbcast.  This is discussed in a TR by me, Cooper and
  37. Gleeson (isis publications list appended).  So, we don't really need
  38. a complex implementation, it turns out, to support a very flexible
  39. protocol suite.
  40.  
  41. Isis is totally decentralized, although some protocols do pass tokens
  42. around that allow the holder to do some distinguished thing, like
  43. ordering two concurrent events.  But, when we do this, the token is
  44. automatically regenerated in the event of system reconfigurations.
  45.  
  46. I think that the more I say on this the more confusing it will get,
  47. short of pointing you again to the detailed model and discussion in
  48. the journal articles, which were written to be precise.
  49.  
  50. >>No, we leave this to the OSF and UI Atlas people... Sounds like you need
  51. >>DCE; then you can ask "can ISIS be used within DCE" and we can reply "sure".
  52. >>(This is no problem...)
  53. >
  54. >    How do Isis and DCE fit together?  Do you make use of DCE RPC's for
  55. >secure communications?  Does Isis use DCE threads?  (I don't know much about
  56. >how DCE offers all these services to applications programmers, so don't assume
  57. >too much.)
  58.  
  59. The fit is pretty much one of "non-inteference".  ISIS programs in
  60. a DCE environment would use the POSIX threads package, aka pthreads,
  61. which ISIS already supports when compiled for MACH.  (Actually, we might
  62. need to edit some include files a little once we get ahold of a real
  63. DCE distribution, but this will not be a problem).  The isis routines
  64. would then be running concurrently with your "normal" DCE application.
  65.  
  66. RPC would be into your application, through DCE RPC, but the various
  67. ISIS primitives could all be called -- so you basically just get both
  68. worlds at the same time.  Since DCE has encyption facilities, you could
  69. invoke these primitives to encrypt data sent in ISIS messages...
  70.  
  71. ISIS itself doesn't use DCE directly, except for the threads package.
  72. In fact, we can use any of a half-dozen threads packages, but our model
  73. is pretty much the pthreads one, so DCE is a particularly close match.
  74.  
  75. By the way, we are working closely with OSF's Research Institute on
  76. adding ISIS functionality to OSF 1/AD.  When this is done, we plan to
  77. have a look at how that functionality might be used within systems
  78. like DCE.  (We aren't particularly biased towards OSF -- we are
  79. also working with everyone else!)
  80.  
  81. Ken
  82. -- 
  83. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  84. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  85. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  86.