[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spread-users
Subject:    Re: [Spread-users] Optimal message size
From:       Yair Amir <yairamir () cnds ! jhu ! edu>
Date:       2001-09-19 18:52:16
[Download RAW message or body]

Sean,

This is non-negotiable between the daemons. They all know this constant.
I think in the coming 3.16.1 release there is a user level constant that specify
it.

There was a discussion on the mailing list in July about message sizes.
I think Jonathan gave a detailed explanation:
http://lists.spread.org/pipermail/spread-users/2001-July/000127.html

Some users wrote in Java code that allow arbitrary length:
http://lists.spread.org/pipermail/spread-users/2001-July/000126.html

	Cheers,

	:) Yair.

Sean Chittenden wrote:
> 
> > You should use the maximal message size (somewhere around 100KBytes).
> > The more you put into one message, the better Spread will utilize the network.
> >
> > How big are your objects?
> 
> This is a library/daemon/framework, so I don't know.  What I'm creating
> is a reliable persistence interface/daemon, so I'm not 100% sure what
> data will be used.  I'd like to be able to store actual files in the
> session, so in cases it'll just be user data (small text strings), but
> in other cases it'll tarballs (could be quite large) and probably jpegs.
> Is the maximal message size a limit that I can change at runtime?  Is
> there any merrit to increasing it to fit the size of the message I'm
> sending over the wire, or would that require some kind of negotiation
> between all of the spread daemons (is there any negotiation right
> now, or are all spread daemons assumed to be at 100KB?)?
> 
> Having the application piece together multi-part messages and then
> reconstructing large objects shouldn't be too hard to write.  -sc
> 
> --
> Sean Chittenden


_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users

[prev in list] [next in list] [prev in thread] [next in thread]