All things related to multicast

["Dale W. Carder" <>]

I'll raise you: source routing in smtp. Use an email address per product per 
site source routed through the topology you want.

Seriously, while souce routing is "deprecated" in smtp, I think all the 
puzzle pieces could be there to build an optimized distribution tree complete 
with queueing / buffering (a big problem w/ multicast, since you can't send 
faster than your slowest reciever), reliable push-based delivery, robust 
error handling inherent in the protocol and a very mature set of daemons and 
toolsets from which to choose.

All you would need to add is the glue to handle maintenance of the 
specialized "mailing lists".

Dale

(this is still before my morning coffee)



On Feb 22, 2013, at 6:32 AM, Steven Wallace 
<>
 wrote:

> In the spirt of popsicle sticks and a hot glue gun, I have another thought. 
> You could build a file distribution network based on rsync running over 
> ssl. That just might work.
> 
> ssw
> 
> On Feb 22, 2013, at 7:00 AM, Gary Parker 
> <>
>  wrote:
> 
>> 
>> On 22 Feb 2013, at 11:51, Steven Wallace 
>> <>
>>  wrote:
>> 
>>> I had no idea multicast was being used for usenet. That's cool. Still, I 
>>> suspect the bit rate for usenet is way south of 3Gb/s. 
>> 
>> Sorry Steve, I didn't make myself clear. Usenet doesn't, afaik, use 
>> multicast. What I was getting at is that, end-to-end, nntp doesn't 
>> guarantee delivery of data from the poster to the reader, so the poster 
>> can employ FEC in the form of PAR2 chunks to ensure that the reader can 
>> recreate any missing blocks of data that didn't get through to their local 
>> usenet node. I see the same method being potentially useful when you can't 
>> guarantee delivery of data via UDP for large datasets over multicast.
>> 
>> Having read the wikipedia article I posted the link to, though, it may 
>> appear that the current iteration of PAR2 may not be suitable for the 
>> volume of data being discussed here. I'm sure there are similar 
>> technologies available that scale better, though.
>> 
>> Gary
>