[Spread-users] FEC support, bw control, msg size, encryption and data resends
jonathan at cs.jhu.edu
Tue Aug 22 15:26:15 EDT 2000
On Tue, Aug 22, 2000 at 02:03:56PM +0200, Charl Matthee wrote:
> I have a few questions about Spread's current and future features:
> FEC support
> Does Spread currently employ any kind of FEC (forward error correction)
> for reliable multicast with no back channel? Is it being reviewed for
> future releases?
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
I'd be interested in hearing if you disagree and how you would use it.
> Bandwidth Control
> Does Spread offer any way to limit bandwidth to specified groups?
Not currently. One of the main research activities of the CNDS lab and
Spread project is adding security services to Spread. That project
includes adding access control and some general resource management
> Maximum 'message' size at 100KBytes
> Does this message size refer to communication between daemons or data
This is the maximum size of a Spread message that can be sent as one
message through the SP_* api. The daemons will break messages up into
smaller datagrams of an appropriate size for the networking technology
being used to actually transmit the packets.
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.
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
> User/group specific multicast IP address allocation
> Spread seems to have good support for user/group specific multicast IP
> address allocation. Is there any support for encrypted data streams to
> run on top of this?
I'm not sure exactly what you mean by "user/group specific multicast IP
address allocation"? Spread does not use IP-multicast addresses for giving
each group a separate 'address'. It gives each group a name (string) and
demultiplexes them itself. It uses IP-multicast purely as a local network
As I mentioned above, we are currently working on adding security services
to spread which will include encrypted data stream. We have a
development version with key generation and encrypted data messages, but
it hasn't been released yet. It will be sometime, hopefully not too far in
> Reliable multicast
> Does the reliable multicast incorporate packet-specific resends of
> data, or does a whole data 'message'/file/object need to be
Each message is broken into small packets and the recovery/retransmission
of lost data packets is done at the packet level. So only the parts of the
message which were actually lost on the network are resent.
Hope this helped. I'm always happy to answer questions.
Jonathan R. Stanton jonathan at cs.jhu.edu
Dept. of Computer Science
Johns Hopkins University
More information about the Spread-users