[Spread-users] Big messages in Spread

[Jonathan Stanton]

On Fri, Jul 20, 2001 at 11:16:33AM -0600, Roel van der Goot wrote:
> 
> Since we were encountering some issues with big messages, I found
> the following two things in Spread that should probably be changed.
> For completeness sake we are using fibrechannel datagrams that have a
> maximum of 964 bytes (MAX_PACKET_SIZE == 964):
> 
>   - MAX_SCATTER_ELEMENTS is defined to be 100 in two files ("sp.h" and
>     "scatter.h").

If your concern is that the same constant is defined twice, that is a
'bug' although 'harmless' since they are the same number. Actually I think
the two uses of MAX_SCATTER_ELEMENTS are actually different and they do
not have to be the same number (but then they need to have different
names) The client interface could allow a different maximum number of
scatter elements in SP_scat_multicast and SP_scat_receive calls then the
daemon uses internally. The actual requirement is that the client does not
send a message larger to total size then then daemon can handle. 

 > 
actually sp.c (from your second email)
>   - scatter.c uses 1440 as a constant instead of (MAX_PACKET_SIZE - 32)
>     where I don't know what the 32 represents. May be the 32 should
>     become a defined constant depending on its meaning.

This is an oversight. 1440 should not be hardcoded in. The 32 bytes is
used to store the packet header. In the daemon code we do have a way to
get that number without hardcoding it. I'll see how the client should know
this. 

Here is the real question, which I would be interested in anyone's
opinions on. 

What should the maximum message size supported by a Spread
client library be? 

Should that size depend on the way the daemon is compiled (i.e.
MAX_PACKET_SIZE)?

Currently the answers are MAX_SCATTER_ELEMENTS * 1440 and sortof ( it
depends only on MAX_SCATTER_ELEMENTS, but if you shrink MAX_PACKET_SIZE
then too large messges can be sent which is buggy)

I think there should be better answers :-)

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