[zeromq-dev] Requirements for reliability

[Martin Sustrik]

Ho John,

> Before this goes much further, may I ask what is meant by
> 'reliability' in this context? I have entered a brief note in the 0MQ
> blog saying that the JMS spec would be a good place to start in my
> mind as we would all be on the same page (pun intended).

As you've noted in your comment, term "reliability" is so vague it 
almost makes no sense to speak about it.

> Yes, the JMS spec contains more than is required, at least for an
> initial version, but it does have some good terms and is well
> understood, I think.
> 
> In that context: if we take Martin's "...reliable request/reply on
> top of TCP transport" comment, what does this mean to the client and
> the server? (Front-end and back-end if you prefer.)

What I mean was pretty straightforward scenario where there are 2 nodes 
communicating. One sends a request a waits for reply. Other one receives 
a request, processes it and sends a reply.

This is a well understood scenario. To make it "reliable", sender has to 
resend the request after a timeout and discard duplicate replies.

If you have some other simple scenario to start with, let's discuss it.

> Reliable to me means that no message may be lost -and if it is, the
> fact has to be recognized and reported-, no message may be delivered
> more than once if so desired, messages may be batched into
> transactions, meaning either all messages in the batch are delivered,
> or none.

This is too generic IMO. Probably not doable in scenarios like pub/sub.

> If this is not what is meant, then please help me with a definition
> of what is being asked!

No idea myself :)

Martin