[zeromq-dev] Hints about async pattern

[Marco Trapanese]

Il 09/04/2012 18:42, Chuck Remes ha scritto:

> I recommend following this approach:
>
> http://unprotocols.org/blog:15
>
> By using a credit-based flow control mechanism you wouldn't need
 > to worry about pings and pongs to limit the queue size. You could
 > limit by message count or by byte count depending on how you
 > implemented the flow control.


I'm playing with this solution.
Because my application send commands I must be sure that each message 
sent by the server is received by the client at the moment.
If a client is down it *must not* receive any old message when the 
connection will be recovered.

If I understand correctly, the credit-based flow control mechanism 
replaces the HWM allowing me to set the queue size down to 1 message 
without any related issue.

Thus after each message received, the clients send back the 
TRANSIT_SLICE. When the server doesn't receive the credit anymore stops 
the transmissions.

Well, it's a kind of a req-rep (or ack) protocol.

Anyway, the (unique) message sent after a client disconnection will stay 
in the queue until the client will be reconnected. And the client will 
receive the message, won't it?

I may use the sequence counter to check if the message is an old one, 
but I think it will fails if I just disconnect and reconnect the LAN 
cable (the sequence counter is initialized at startup).

Of course I could implement a timeout on the client side: if no messages 
are received for a while, I reset the sequence counter.
But now I need again a periodic transmission of some dummy data... we 
come back to the ping-pong protocol!

I'm sure I miss something. May you help me to better understand how to 
manage this situation?

Thanks
Marco