[Spread-users] Big messages in Spread

Jonathan Stanton jonathan at cnds.jhu.edu
Fri Jul 20 16:03:17 EDT 2001


On Fri, Jul 20, 2001 at 08:32:59PM +0100, Ben Laurie wrote:
> Jonathan Stanton wrote:
> > What should the maximum message size supported by a Spread
> > client library be?
> 
> Ideally, as big as you can fit in memory (real or virtual). The
> application can decide how stupid it is to do that.

The problem is that not only this client has to store the message in
memory, but also all of the daemons and any other clients who are
receiving it. Also, since many messages may be in transit (or buffers) at
once, the actual memory usage is more like C * N * max_message_size, where
C is the number of clients on one machine and N is the number of buffered
messages. And one client's large messags interfere with the service given
to other clients who may only be using small messages.

Also, most datagram protocols have a 'max message size' for practical
reasons, cause if you don't then what is a 'datagram'?

An issue that does not come up with 'unordered' delivery is that messages
that are ordered after a largemessage will be delayed until the large
message is fully received (which could be arbitrarily long if 'unlimited'
size messages are allowed). This is still true even with message size
limits (a 1 byte message is delayed by a 80Kbyte message in front of it)
but the size limit is chosen to 'work well in practice' (whatever that
means...since it depends on network technology, machine power, types of
messges, etc)

> > Should that size depend on the way the daemon is compiled (i.e.
> > MAX_PACKET_SIZE)?
> 
> Only insofar as it isn't possible to avoid.

Ok. I agree, but it probably isn't possible to avoid unless you want the
daemon to end up rejecting messages that the client thought were of ok
size because the daemon has a smaller limit.

Thanks,

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------





More information about the Spread-users mailing list