[zeromq-dev] Client-Server synchronization with timeout

[Christopher Jakob]

Hello,

for a business application I would like to use ZMQ with kind of a 
two-way commited protocoll:
A req/rep between server and client that is guaranteed that the 
transmitted changes are processed either on both or on none of the systems.
The abort-condition of the req/rep is a timeout, that means, that the 
client needs the reply in a certain time frame  otherwise the request 
has to be
reverted or dropped, depending on how far the server has processed the 
request. The dimension of the timeouts a talk about is about 300-500ms.

Example:
A client sends a login request. The server checks certain settings and 
then changes the state of the user in the database to "logged in".
If the server needs to long to process, or network latency is too high, 
the client aborts the login, e.g. showing a timeout message.
Now the server has to rollback the change to the database, otherwise the 
client would appear as "logged in" in the database although it isn't,
and a further login request would result in wrong behaviour.

In the documentation I found the different pirate patterns, which are 
able to detect timouts, but unfortunatelly only from the clients point 
of view.
The worst case using those patterns would be the client sending a 
request, the server doing a change to a database, but not answering fast
enough, would lead to inconsistent data between client and server.  If 
the server would be able to detect a client closing the connection,
that would solve my problem, because then I could use the lazy pirate 
pattern, simply closing the socket if the server is too slow.
The server would recognize the closing socket and know that he has to 
rollback the possibly done changes.
I thought that would be the easiest way to inform the server about being 
too late, but unfortunatelly did not found a way to recognize client
socket shutdown with the API.

Another possibility would be to implement a kind of 3-way handshake:
Client sending a request -> server sending reply -> client answering 
with ack or nack depending whether the reply was in time or not.
But then I have to deal with possible loss of ACK and NACK messages, 
which leads me to a chicken-or-the-egg-dilemma...

Any help or comments would be really appreciated

Kind regards
Christopher