Hi,<br><br><div class="gmail_quote">2008/6/3 John Lane Schultz <<a href="mailto:jschultz@spreadconcepts.com" target="_blank">jschultz@spreadconcepts.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ultimately, the only way you can be 100% sure your message was received<br>
and processed by the far end is for an application level ACK<br>
indicating exactly that.<br>
<br>
You can get a good way toward that by having your applications join<br>
the same groups and then monitoring the membership changes. So long<br>
as Spread reports your "buddy" as in the group, then there is a high<br>
likelihood that he is getting and processing your messages. Of<br>
course, this is still not 100% sure, but it might be good enough for<br>
your needs.<br>
</blockquote><div><br><br>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...<br>
<br><br>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).<br><br>Regards,<br><br>Florian<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cheers!<br>
John<br>
<br>
---<br>
<font color="#888888">John Lane Schultz<br>
Spread Concepts LLC<br>
Phn: 443 838 2200<br>
Fax: 301 560 8875<br>
</font><div><br>
Tuesday, June 3, 2008, 5:21:01 AM, you wrote:<br>
<br>
> Alexey Zakhlestin wrote:<br>
>> well, first thing which comes to mind is sending the confirmation<br>
>> message in reply ;<br>
> If the original sender is not available then due to whatever reason then<br>
> that would fail. The sender would then need to resend, but the receiver<br>
> already assumed that the sender received the reply. Hopefully you can<br>
> see the dilemma from that.<br>
<br>
> If one needs to dispatch small units of work to many servers which may<br>
> be up or down at any moment, one has to be sure that the target received<br>
> the message and that it can handle it, else it must be dispatched to<br>
> another server. The units of work(In my case) would be too small and<br>
> sensitive to latency for a message/job queue. Therefore I am evaluating<br>
> spread as a low level communications medium.<br>
<br>
<br>
<br>
</div><div><div></div><div>_______________________________________________<br>
Spread-users mailing list<br>
<a href="mailto:Spread-users@lists.spread.org" target="_blank">Spread-users@lists.spread.org</a><br>
<a href="http://lists.spread.org/mailman/listinfo/spread-users" target="_blank">http://lists.spread.org/mailman/listinfo/spread-users</a><br>
</div></div></blockquote></div><br>