All things related to multicast

["Dale W. Carder" <>]

On Feb 22, 2013, at 9:04 AM, Dale W. Carder wrote:

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

If you're willing to mange a distributed system, you could architect
the distribution tree to have multiple layers of mailing-list like
expansion from hub sites.  

Then you don't need source smtp routing and could take advantage
of multiple mx records to get redundancy, be able to handle topology 
changes, and hub site failures.  The feature you want to exploit is 
that mail daemons know not to duplicate messages destined to "users"
at the same server.

Well, I've at least managed to convince myself that this isn't
entirely crazy.  Since your number of end sites is low, maintaining
a sane distribution tree is not too bad or at least probably easier 
than beating more and more topology locality awareness into bittorrent,
and having clients know what to pull rather than get data pushed.

Dale

  
> 
> 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
>>