Re: Why GNU Mach is so different?

[Farid Hajji]

> > Of course, one can always simulate multicasting or avoid it completely.
> > That is not a big issue.
> 
> Being a parallel programming person: the whole point of multicast is low 
> level support in network so that collective communications attain favorable 
> speedups. IOW, it is similar to a multi-port communication model whereas such 
> a simulation that you mention would make your collective communications 
> single-port.

This is mainly a question of perspective. Either you do multicasting
at the IP layer, or you do it at application layer. From the point of
view of the client applications, communications are still always
directed towards group(-addresses).

> Note that very few distributed systems make use of IP multicast. There is a 
> good reason for this: multicasting is not yet reliable. However, it is said 
> that multicast works reasonably well in IPv6. I haven't tested that myself.

You're right when you mention that IP multicasting is seldom used in
distributed systems. However, this has nothing to do with the alledged
unreliability of IPv4 multicasting. The reason for _not_ using it
is twofold:

1. Most distributed systems nowadays are pretty strongly coupled. In such
   a case, using IP for communications incurs too much overhead. In other
   words: As long as the distributed system shares a (non-switched) LAN,
   IP is often avoided completely. I'm not even speaking of tightly coupled
   shared memory systems here which don't need IP at all ;)

2. IP multicasting is pretty reliable in the Net/3 codebase used in
   the TCP/IP stacks of *BSD (I don't know about the Linux or even
   Solaris codebase). However, IP multicasting must be enabled in
   the routers, if you want to use it in a larger LAN or even in
   WANs. Unfortunately, not every router administrator enables
   PIM by default. This means that the Internet is currently not
   a very multicast-friendly environment.

I've looked closely at the KAME IPv6 implementation of FreeBSD and done
some tests with it. As far as I can see it, my regression tests of
multicasting worked flawlessly there. However, the problem will still
remain in IPv6 on a global scale, because it is still an administrative
problem to enable multicasting in the routers.

> Another reason why multicasting is not exploited too much may be the 
> following: the kind of multicasting the IP people talk about is things like 
> streaming video broadcast over long distances whereas parallel/distributed 
> people would like something that would give them a very efficient way to do a 
> broadcast/scatter/gather/reduce etc.

Sorry, but IP multicasting has nothing to do with streaming video broadcast.
vic, vac, sdr etc... are not the only multicasting tools available and there
is much more than Mbone or 6bone out there. Its just not so visible to the
outsiders ;-).

IP multicasting provides a best-effort service of multicasting IP
packets across an internet. No more and no less. If your apps accept
packet loss (as in video streaming), you'll simply use UDP over IP
multicast, else you'll use TCP. There is nothing fundamentally different
than in the simple unicast mode.

I'm a parallel/distributed person myself and I agree that efficiency
is extremely important. As soon as you come to things like distributed
shared memory, task migration and the like, you need fast (and preferably
reliable) networking. I use [multicast] IP only when I need to cross
a router boundary. The "normal" case bypasses IP completely and uses
raw ethernet frames or (when applicable) ATM cells. This was a good
decision back in the old days of slower CPUs and 10 MBit/s ethernet,
but I'm slowly coming to the conclusion that it would be better to
switch back to IP and spend more time on optimizing the IP codebase
in the hosts themselves ;)

> Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
> Comp. Sci. Dept., Bilkent University, Ankara
> www: http://www.cs.bilkent.edu.tr/~erayo
> GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.