home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / isis / 396 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.0 KB
  1. Path: sparky!uunet!pipex!unipalm!uknet!dcl-cs!nigel
  2. From: nigel@comp.lancs.ac.uk (Nigel Davies)
  3. Newsgroups: comp.sys.isis
  4. Subject: Groups in a mixed media setting
  5. Message-ID: <1993Jan26.165131.28041@comp.lancs.ac.uk>
  6. Date: 26 Jan 93 16:51:31 GMT
  7. Organization: Department of Computing at Lancaster University, UK.
  8. Lines: 78
  9.  
  10.  
  11. In response to Ken's message suggesting that more general distributed systems/
  12. group issues be discussed in this group I thought people might be interested in
  13. some experiences we've had of using groups in a mixed media environment. 
  14. I'll follow these with a few questions I hope someone might be able to help 
  15. me with.
  16.  
  17. For the last few years we have been building a platform to support distributed
  18. multimedia applications. The platform has been based on the ANSA computational
  19. model (essentially a client-server object model) and on the ANSAware 
  20. implementation of this model.
  21.  
  22. The question which we had to deal with was how to model the transmission of
  23. media types such as audio and video. The solution we adopted was to introduce
  24. new objects called stream objects which represent the transmission of continuous
  25. media. Application developers simply plumb together sources and sinks of 
  26. continuous media data using these stream objects.
  27.  
  28. The next question was how to model multicast of continuous media info.  We had 
  29. already done a _very_ simplistic implementation of object groups for 
  30. invocation, so it seemed natural to try and exploit this for continuous media
  31. transmission (the model not the implementation). In fact, we simply allowed
  32. programmers to group together sources and sinks, and specified that streams
  33. connected together source and sink groups rather than individual devices.
  34.  
  35.     O                                 O
  36.      \                                    /
  37. sources 0- |group interface ===stream======group interface| -O  sinks
  38.      /                                     
  39.         O
  40.  
  41.                  information flow ---->
  42.  
  43. This way we could exploit the group management functionality to look after
  44. control of new objects joining the groups.
  45.  
  46. The programmer can also use the groups for control purposes, e.g. sending
  47. start/stop messages to the devices which have been grouped together.
  48.  
  49. Finally, in order to allow us to use groups for management purposes we
  50. implemented a form of group hierarchies which allowed us to provide equivalent
  51. functionality to those systems supporting domains (I can point people in the
  52. direction of references if anyone wants more details on any of this work).
  53.  
  54. We are now entering a period of 'reflection' as far as this model goes and
  55. I'd welcome any thoughts, specifically with reference to the following:-
  56.  
  57. 1) I seem to remember that there was some talk of collaboration between APM
  58.    (the developers of ANSAware) and Cornell a year or so ago. Did this ever
  59.    come to anything ? (The most recent version of ANSAware still does not
  60.    provide support for groups so I am guessing not ...)
  61.  
  62. 2) It is some time since I have seen any ISIS documentation. Does ISIS support
  63.    hierarchies of groups, and if so what sort of event ordering guarantees
  64.    does it provide ?
  65.  
  66. 3) One of the reasons for using the group abstraction for describing multicast
  67.    /multidrop continuous media configurations was to provide the programmer
  68.    with similar tools for carrying out both invocation and continuous media
  69.    transmission. However, judging by the recent postings there may not be a 
  70.    requirement for multidrop invocation groups.
  71.  
  72. 4) We are now considering an implementation of the platform using mobile
  73.    radio as the communications medium (supporting a _very_ limited range of
  74.    media types). Does anyone have any experiences in implementing group 
  75.    protocols over a radio link ?  More generally, does anyone know of any 
  76.    distributed systems work aimed at such an environment ?
  77.  
  78.  
  79. Cheers,
  80.  
  81. Nigel Davies.
  82.  
  83. JANET:    nigel@uk.ac.lancs.comp      | POST: University of Lancaster,
  84. UUCP:    ...!mcvax!ukc!dcl-cs!nigel  |       Department of Computing,
  85. ARPA:    nigel@comp.lancs.ac.uk         |       Bailrigg,
  86. VOICE:    +44 524 65201 Ext. 3132     |        Lancaster, LA1 4YR
  87. FAX:    +44 524 381707            |        UNITED KINGDOM
  88.