[Spread-users] Delivery confirmation

[Florian Merges]

Hi,

2008/6/3 John Lane Schultz <jschultz at spreadconcepts.com>:

> Ultimately, the only way you can be 100% sure your message was received
> and processed by the far end is for an application level ACK
> indicating exactly that.
>
> You can get a good way toward that by having your applications join
> the same groups and then monitoring the membership changes.  So long
> as Spread reports your "buddy" as in the group, then there is a high
> likelihood that he is getting and processing your messages.  Of
> course, this is still not 100% sure, but it might be good enough for
> your needs.
>


You can also make a wrapper and send an ACK on reception/reading of the
message, doing it optional when connecting to spread or listening to new
messages. It will mean that for each incoming message you will generate a
return message. From the other point of view, from the sender, you will wait
to get an ACK from all the buddies in the channel; then it's up to you and
the problem you try to solve if you can just resend the message to the
group, send it to the private group fo the one that didn't send an ack,
ignore it, log it, or whatsoever...


The solution proposed by John, is simple and doesn't impact so much
performance wise, as usually you're already taking care of membership
changes (events).

Regards,

Florian



>
> Cheers!
> John
>
> ---
> John Lane Schultz
> Spread Concepts LLC
> Phn: 443 838 2200
> Fax: 301 560 8875
>
> Tuesday, June 3, 2008, 5:21:01 AM, you wrote:
>
> > Alexey Zakhlestin wrote:
> >> well, first thing which comes to mind is sending the confirmation
> >> message in reply ;
> > If the original sender is not available then due to whatever reason then
> > that would fail. The sender would then need to resend, but the receiver
> > already assumed that the sender received the reply. Hopefully you can
> > see the dilemma from that.
>
> > If one needs to dispatch small units of work to many servers which may
> > be up or down at any moment, one has to be sure that the target received
> > the message and that it can handle it, else it must be dispatched to
> > another server. The units of work(In my case) would be too small and
> > sensitive to latency for a message/job queue. Therefore I am evaluating
> > spread as a low level communications medium.
>
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20080604/7b7e59df/attachment.html