[Spread-users] Re: FEC support, bw control, msg size, encryption and data resends

[Charl Matthee]

On Wed, Aug 23, 2000 at 12:00:02PM -0400, spread-users-admin at lists.spread.org wrote:

> No Spread currently does not use FEC. We have discussed it some, but
> because Spread always provides a membership service and has it's own
> wide-area multicast network (i.e. it doesn't use IP-multicast for wide
> area dissemination). FEC did not seem to provide a real benefit for
> Spread. 
> 
> I'd be interested in hearing if you disagree and how you would use it.

We provide a satellite card service for users. The satellite
connection is fast with high latency (as these things are :). The
user basically uses the satellite card to receive data and his
normal connection (diginet, ISDN, modem, etc.) to send data.

What we wish to do is multicast data to these users via the satellite
with no back channel (i.e. no connection to the internet). Because
there is no back channel most reliable multicast implementation can't
cope (they need the back channel to request packet resends).

FEC would basically make up for the fact that there is no back channel
to request resends because the receiver would be able to reconstruct
the packet that was sent. Something similar to reliable PGM.

> The maximum message size is essentially the largest 'single' object you
> can send through spread and get the guarantees provided to a single
> message (such as EVS, agreed ordering, etc). If you want to send 500Kb
> say, you would send it as 5 separate spread messages and each one would
> have whatever guarantees you requested, but it would be possible for one
> message to arrive before a new member joined the group and another message
> to arrive after the new member joined.

Shouldn't the segmentation of the object you wish to send be done as
an abstraction to programmer/user via the API? I basically want to
send data and have a guarantee on it's delivery. I don't want to worry
about creating data segments that are of the right size. I just want
to send the data and it must magically appear on the other side.
 
> Because group communication is based on a datagram (as opposed to stream)
> model, you have to pick some maximum and 100kb seemed a good tradeoff for
> now. 

Sure. But I still feel this size should be abstracted via the API :)

Perhaps my understanding of how Spread works is a little (or quite a
bit) flawed :) If so, please educate me.


Ciao

Charl
__________________________________________________________________________

   The impossible is easy; it's the unfeasible that poses the problem.
__________________________________________________________________________

      Charl Matthee                              charl at mailgate.net
      Reality Manufacturing                         +27 11 721-3800
__________________________________________________________________________