[Spread-users] GROUPS_TOO_SHORT || BUFFER_TOO_SHORT

[David Shaw]

On Mon, Mar 18, 2002 at 09:56:18AM -0500, Jonathan Stanton wrote:
> On Mon, Mar 18, 2002 at 10:54:40AM +0100, Koorosh Alahiari wrote:
> > Hi All,
> > 
> > Could anyone tell me what the following code segment
> > in user.c mean?
> 
> By default if the buffers you pass to a SP_recv call are too short
> to hold the body of the message you are receiving,or if the groups
> buffer is too short to hold the list of groups or members, then the
> SP_recv call will return GROUPS_TO_SHORT or BUFFER_TO_SHORT and NOT
> dequeue the message (so the next time you call SP()recv you will get
> the SAME message).
> 
> The idea is that you can call SP_recv again with larger buffers and
> successfully get your message.
> 
> Now you may not care about creating larger buffers and may just want
> to truncate any data or groups that are too long and just get the
> portion of the message at teh beginning that you have room for. That
> is what teh DROP_RECV flag does. It tells SP_recv to give you as
> much as possible and then drop the rest of the message.

What would be really nice here would be a bit set to indicate that
this truncation had actually happened.  For example, an application
that did not care if its messages were truncated or not (but did want
to know if it happened) could always pass DROP_RECV.  A bit set
(perhaps in service_type) would indicate that the truncation was
necessary.  If the message did happen to fit in the buffer, then
DROP_RECV had no effect and the bit would not be set.

This allows for simpler application code and can halve the number of
calls into the Spread library (and halve the number of thread locks,
etc.).

David

-- 
David Shaw          |  Technical Lead
<dshaw at akamai.com>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies