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

[Toerless Eckert <[e-mail]>]

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.

From the applications i know, it seems to me that c) is today only
predominant in application that have lots of good reasons to avoid
servers. The typical examples of course are those in which the
server(s) would be in danger of being sued or bombed away anyhow
(eg: typical file-sharing software or military applications). 

For typical commercial applications you almost always resort to
a) or b), and then b) typically has a lot of advantages on access
control, synchronization, etc., and a) is mostly used in cases
where the added efficiency of avoiding passind data through a
server becomes important. So from that perspective i think that
SSM quite well, if not better fits the typical application retuirements
than compared to ASM.

Cheers
	Toerless
_______________________________________________
Ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm