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

[Chetan Gadgil]

I had intended to use DoS as an example and not as an example of an
attack against a spread process. (Analogy: a sender thrashing a group is
the attacker as in a DoS attack)

In a DoS, the sender is the culprit. Similarly, within the domain of
spread communications, the sender should perhaps be the designated
culprit. (IMHO sending will always be faster than receiving - i.e. a
receiver can't get the message before it is sent.)

In my case, I was able to get around this by increasing the number of
messages buffered before the receiver is killed.

Note that these things are not critical for me, so this is not an attack
against the Spread toolkit or the Spread team.

I still think that the sending can flood a group no matter how fast a
receiver receives them. Imagine a group where hundreds of senders are
sending and only one member is receiving as fast as possible. If it were
possible to throttle the senders, it might be more manageable at the
application level.

Of course, as usual, a variety of things can always be implemented at
the application level, but it "would be nice" if that were not
necessary. I may be overstepping my bounds here, but I just wanted to
use the mailing list to "multicast" my opinion.


In my suggested approach, the flow control responsibility is not on the
sender. It is more on "Spread", or more precisely, on the client side
spread library. The client side spread library is the first "receiver"
of the message (i.e. SP_multicast) and this call can become more
expensive (take longer and longer) if "abused" by the senders. (i.e.
excessive buffering of messages)

In some cases, this behavior may be more "right" than others, which is
why I said it is a matter of perspective.


In any case, I really like the Spread toolkit - excellent work.


Regards
Chetan


> -----Original Message-----
> From: George Schlossnagle [mailto:george at omniti.com] 
> Sent: Wednesday, December 24, 2003 4:27 PM
> To: cgadgil_list at cxoindia.dnsalias.com
> Cc: jgreen at spreadconcepts.com; spread-users at lists.spread.org
> Subject: Re: [Spread-users] Spread daemon -8 and -11 errors
> 
> 
> 
> On Dec 24, 2003, at 5:20 AM, Chetan Gadgil wrote:
> 
> > :)
> >
> > I guess it's a matter of perspective. In a typical DoS attack, I see
> > the
> > sender as the culprit.
> 
> Spread's not a terribly secure protocol to begin with.  There are 
> plenty of ways to disable or DoS a Spread network without 
> flooding it.  
> Spread participants are all considered trusted.
> 
> >
> > In practical terms, a sender can always re-send a message 
> if sending 
> > fails in the first place. However, a receiver will not know 
> how many 
> > messages it has missed if it were forced to disconnect. 
> This would be 
> > a redefinition of "reliable" delivery.
> 
> The sender will always know who has received the message and who has 
> not - the sender can always opt to resend an important message for a 
> client that was disconnected for any reason.  Reliable delivery isn't 
> magical.  If a node becomes separated due to a network segmentation, 
> you cannot successfully deliver to that node.  You might 
> posit that you 
> could wait till that node becomes available, but that's not very 
> realistic as the node may be offline indefinitely.  Similarly, a 
> receiver with severe flow-control problems potentially threatens the 
> stability of the ring.  This is that receivers problem, not 
> the senders 
> problem, and the receiver should separate itself from the ring.  
> Putting the responsibility for the receivers flow-control on 
> the sender 
> is not a good assignment of responsibilities at the protocol level.
> 
> If this is something you really need, you can of course 
> implement this 
> sort of global flow on top of spread in your application.
> 
> 
> >
> > The send can be made more expensive. E.g some function of 
> the number 
> > of messages buffered for a given group.
> >
> >
> > HISTORY, n.
> >   An account mostly false, of events mostly unimportant, which are 
> > brought about by rulers mostly knaves, and soldiers mostly fools.
> >     - Ambrose Bierce, The Devil's Dictionary
> >
> >
> >> -----Original Message-----
> >> From: George Schlossnagle [mailto:george at omniti.com]
> >> Sent: Wednesday, December 24, 2003 3:42 PM
> >> To: cgadgil_list at cxoindia.dnsalias.com
> >> Cc: jgreen at spreadconcepts.com; spread-users at lists.spread.org
> >> Subject: Re: [Spread-users] Spread daemon -8 and -11 errors
> >>
> >>
> >>
> >> 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.
> >>
> >> But it's the receiver that is being slow.  There are 
> potentially many 
> >> receivers and many senders - you should kill the culprit.
> >>
> >> George
> >>
> >> // George Schlossnagle
> >> // Postal Engine -- http://www.postalengine.com/
> >> // Ecelerity: fastest MTA on earth
> >>
> >
> >
> // George Schlossnagle
> // Postal Engine -- http://www.postalengine.com/
> // Ecelerity: fastest MTA on earth
>