[Spread-users] Session disconnect

[Jonathan Stanton]

Theo is correct that Spread provides information allowing everyone in a
group (including the sender if they join the group) to know what messages
everyone received. So If someone drops out, you know that and you can resend
the messages you want them to get once they rejoin. 

If you want to avoid having to resend messages upon reconnection, then you
do need to prevent the disconnection from occuring. To do that you HAVE to
do application level flow-control. In your example, the applications do not
do anything with the messages, but normally the application will have to
process the message in some way, even if just to print it on the screen or
to a log file. It is always possible for that processing to take longer then
it takes for a sender to send, so to make sure the receivers keep up you
have to slow down the senders to the rate fo the receivers. The thing to
realize is that doing this does NOT slow anything down. You can do flow
control that allows the receiver to work as fast as possible at all times,
so your system (app + Spread) is running at it's maxium throughput. The fact
that Spread along can process messages faster isn't relevant because it is
useless for spread to process messages that the app can't do anything with.



> On Friday, March 8, 2002, at 09:20 AM, koorosh.alahiari at ids.allianz.com 
> wrote:
> >I was wondering if anyone could explain to me the
> >reasoning behind the forced shut down of slow
> >receivers. This kinds of defeats the object of
> >Reliable Multicast data delivery.
> >
> >I was told on a previous mail that spread
> >drops clients BUT it does NOT drop messages
> >so whenever my receivers were dropped I
> >tried an immediate reconnection and found
> >that about 30% of my messages were lost.

Spread "RELIABLE" deliver guarantees to deliver the message to ALL connected
applications with no chance of loss. However, if apps disconnect then of
course they will miss messages. What else could spread do? It can't store
the messages forever in the off chance the client reconnects. 

Spread is an online system, not a store-and-forward or persistent message
queue (althought implementing such a service on top of Spread is pretty
easy).

> >
> >I would rather avoid implementing an ACK
> >mechanism since this would slow down the
> >very respectable performance of spread!

As I said above, flow control does not have to slow down Spread, it only 
slows down the app to run at the speed of all the other apps.

In some applications you do not want to run at the speed of the slowest
receiver, in that case you have to drop messages, or do a layered approach
with multiple groups like some streaming  video-encoding systems do.

On Fri, Mar 08, 2002 at 10:09:54AM -0500, Theo Schlossnagle wrote:
> 
> You don't need to implement an ACK mechanism.  Spread provides you with 
> this information.
> 
> Spread will notify the _sender_ that the group has changed when your 
> receiver is disconnected.  so you didn't "loose" any messages.  You 
> should have been aware that you were sending them to a group that didn't 
> contain the member you were expecting to hear them
> 
> Spread's group semantics provide a powerful and sufficient mechanism for 
> implementing application-level reliable delivery.  Spread itself, only 
> implements daemon-to-daemon (network) reliable multicast.

Just to be clear, even the daemon-to-daemon reliablity is reliability NOW,
in the online sense. Spread does not store messages for daemons who are down
or crashed. It does guarantee that all alive daemons get teh messages and
then each daemon guarantees that all the clients get the messages they need
also.

Jonathan

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