On Wed, Feb 23, 2011 at 12:09 PM, Chuck Remes <[email protected]>wrote:
> > On Feb 23, 2011, at 11:31 AM, Pieter Hintjens wrote: > > > On Wed, Feb 23, 2011 at 6:25 PM, Chuck Remes <[email protected]> > wrote: > > > >> If you really need reliable delivery of each published message, then the > Pub/Sub pattern is not appropriate. You should use the REQ/REP pattern > because you'll need to acknowledge each message. > > > > Even that won't guarantee delivery :-) What if your acknowledgment gets > lost? > > True. Then you need timeouts and retransmissions. Definitely complicated > stuff... > > > Plus it adds extraordinary latency to traffic. Depending on your > > application, you would want some kind of asynchronous negative > > acknowledgment, i.e. "I'm missing data X, please (re)send". Possibly > > out of band so the normal pubsub traffic can scale to many clients > > over multicast. > > Batching up the missing sequence numbers can be difficult. I like using a > "sliding windows" algo for acknowledgement. You essentially end up > recreating the sliding windows logic from zmodem, tcp, etc. > This, this, this. By the time you layer on all the things you need to implement to achieve reasonable reliability guarantees, you will have IMPLEMENTED tcp... poorly. If you need reliable messaging, you need tcp. The only way around this is to NOT need reliable messaging. If there's no possible way to avoid reliable messaging, then get used to using tcp. Seriously. You will save yourself endless heartache. The interesting discussion then becomes figuring out ways to avoid or relax the reliability requirement. That's a complex topic and the tradeoff choices tend to get made for domain-specific reasons so the solutions frequently fail to be useful in the generic case.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
