[Spread-users] Spread daemon -8 and -11 errors

[Theo Schlossnagle]

On Dec 24, 2003, at 2:43 AM, Chetan Gadgil wrote:
> Ideally, the flow control should be done by the spread library itself.
> If the messages are pushed at a much higher rate than they are pulled,
> the "push" operation (SP_multicast) can become progressively more and
> more expensive in terms of time. i.e. it will take progressively more
> time to return from the call. (This can be made "intelligent" and
> configurable - per group, type of message etc.)
>
> In any case, killing the receiver seems un-intuitive. If at all, you
> should kill the sender.

Chetan,

That would mean that in a stable network of 5 nodes sending "fast" 
group communication traffic, someone only needs to connect and not read 
to bring the whole conversation to a halt -- it would be a slow reader 
and cause everyone else to slow down.

Instead, disconnecting the slow receiver while still maintaining the 
group membership semantics of message delivery is a viable and more 
reasonable approach.

Basically, the flow control you speak of can be built in the 
application level on top of what exists.  But, what exists now could 
never be built on top of the framework you suggest.

Open groups complicate things as the publishers are not necessarily 
participating the in receiving group and may not be privy to the 
delivery of sent messages.  In closed groups you can implement the flow 
control you desire and if you require open semantics, you simple need 
to utilize on closed "control group" to implement flow control in an 
open group as Spread enforces its delivery semantics _across_ groups.

I will not argue that this task may be too intimidating for a new user 
to accomplish and it is reasonable to need such a framework.  Also, it 
has likely been built n times by n different parties.  I suggest an 
initiative to build a generic, intuitive flow control library built on 
top of lib(t)spread that provides these semantics.

What does everyone thing about that?

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth