[zeromq-dev] Clear socket's cache

[Dorin Ciobanu (dciobanu)]

Thanks for answering! I want some clarifications please:

With HWM = 1:

1. The data arrives to my server application on a [relatively] slow link, and I forward it to my client application on a tcp://127.0.0.1:xxxx queue.
   Does this mean that if I get a EAGAIN, I do not have any clients connected to my PUSH socket?

2. Having HWM set to 1, would it still leave the possibility of having one old message delivered after re-connect?

Cheers,
Dorin

-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Mikko Koppanen
Sent: 15 February 2012 12:51
To: ZeroMQ development list
Subject: Re: [zeromq-dev] Clear socket's cache

On Wed, Feb 15, 2012 at 12:28 PM, Dorin Ciobanu (dciobanu)
<dciobanu at cisco.com> wrote:
> Hi!
>
>
>
> My application uses a session oriented design.  I have a PULL socket in a
> client app and a PUSH socket in a server app. Sometimes my client app goes
> away, and I do not know a way to detect this in my server, so I keep sending
> messages into the PUSH socket (using non-blocking flag).
>
> When client application starts, it asks for the queue address from the
> server app (using a non-ZMQ mechanism). At that moment, I do something to
> close the old session and initialize a new session, then tell the client the
> address to connect to for pulling messages.
>
> Unfortunately, my client app gets a few "old" messages before getting new
> ones.
>
>
>
> What is the best solution for this? Is there a way to "clear the cache" on
> the socket? Or is there a way to detect a client is no longer connected?
>
> I would like to avoid close/bind because it's a multi-user machine (windows)
> with concurrent processes that quite actively take and release TCP ports. I
> could end up with the port occupied by competition and that leads to a whole
> list of things I have to take care about.
>

Hello,

without knowing more about the application here are some options that
come into mind:

1. If you can rely on clocks on the client and the server you could
timestamp the messages and expire them on the client side if the
delivery has taken too long. This would effectively allow you to not
process the messages even though they are delivered.

2. Use HWM [1] to limit amount of messages that get pushed into the
pipe. For example setting HWM to very low value you should get EAGAIN
if the client is not there to receive them.

3. Use a different socket type, such as PUB/SUB where the HWM action
is to drop the messages [2]. This is more of a radio broadcast model
(which you seem to be after) where messages are delivered to everyone
listening and when clients tune off they won't get the messages.

Thanks,
Mikko

[1] http://api.zeromq.org/2-1:zmq-setsockopt#toc3
[2] http://api.zeromq.org/2-1:zmq-socket#toc9 (HWM action)
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev