Re: [ssm] Re: last call comments on ssm-arch doc

[Toerless Eckert <eckert@cisco.com>]

One note on the discussed application requirement: If you're
building a pure ad-hoc multi-peer application then what was said in before
on this thread is correct. One could argue though that in face of
overwhelmingly web based or bound applications client/server models
for application architectures have become more ubiquitous because
they provide easier architectural solution to some typical problems,
and if such a client/server architecture is used, then the use
of IPmulticast or SSM specifically can easily be designed to be
really "single source". Eg:

If you're building the white board application as pure peer to peer,
each peer has to become a SSM channel source. If you implement the
application as a client/server system, the clients could unicast to
the server, and the server would have one SSM channel to all clients.
Advantages: Easier model for access control, session management
and ressource allocation then in a full peer to peer model. Given
that today most networked applications are somehow started via the
web, makes it quite easy to imagine the typical solution to be one
involving some web server applet or the like.

So, architecturally, i think one can make three classes of
SSM peer-to-peer applications:

  a) client/server control and data:
     clients send unicast to server, server multicasts on one
     or multiple SSM channels back to clients.
  
  b) client/server control, peer-to-peer data:
     clients have control connection with server to learn
     about peers multicasting. Data itself is multicasted
     on SSM channels from each client to other interested
     clients.
  
  c) peer-to-peer control and data:
     There is no central server. Instead new peers have to
     somehow discover at least one existing peer, who can then
     signal to all other peers the existance of this new peer.
     This peer-to-peer control connections can be unicast
     with some topology between peers or can be SSM.