On Fri, 11 Oct 2002, Jerry Asher wrote: > First of all, I know nothing about IP Multicast.
Me, too. Sorry. But that won't prevent me from asking a couple of questions anyway... > I believe there are too many systems to use typical tcp/ip unicast > connections, and it strikes me that this may be a good use if broadcast or > ip multicast. Why do you think this is too many to use conventional tcp? Isn't one of the reasons we choose AOLserver that it scales? > And since I believe that broadcast and ip multicast are UDP and inherently > unreliable, what are the common techniques used to make for a reliable > multicast? I think part of the definition of multicast is that the source is unaware of the state of the individual receivers. A source has to include "key frames" (to borrow terminology from video broadcasting) so that receivers can pick up a multicast in the middle, or drop a few frames, and still make sense of the bit stream. If you want to be sure that every receiver obtains perfect data, and to guarantee that each receiver gets all data, I don't think multicast is going to work. On the other hand, if you can tolerate some imperfect data among the receivers, it might work just fine. You could also consider using DNS to propagate the data, with caching servers at various points in the network, assuming you feel the traffic would overwhelm a single server. Replicated LDAP servers might do the trick, too. Or even replicated MySQL servers. I don't think multicast is going to work well with HTTP, though, because HTTP pretty much requires data exchange between broadcaster and receiver, and multicast pretty much excludes any data from reaching the broadcaster from the receiver. I'm curious to find out what you learn, though. Pete.
