[zeromq-dev] What is the best 0MQ socket configuration for an event server?

[John McLaughlin - PTIR]

Thank you Martin.  Yes, I was following that thread and agree it would
address my need.  However, with a dynamically assigned (and short-lived)
PUB/SUB Port# I can achieve the same thing at the application level.

Can you see any problems with having short-lived (minutes) PUB sockets
that are auto-assigned an available port, and that can be queried for
the actual port #?  They would need a "destructor" as well (though this
might be simply closing them).

 
John McLaughlin
PROMISE Technology, Inc.

John.McLaughlin at Promise.com
-----Original Message-----
From: Martin Sustrik [mailto:sustrik at 250bpm.com] 
Sent: Tuesday, August 31, 2010 11:12 AM
To: 0MQ development list
Cc: John McLaughlin - PTIR
Subject: Re: [zeromq-dev] What is the best 0MQ socket configuration for
an event server?

Hi John,

> I have a need that does not seem to have a natural solution in 0MQ,
but
> maybe I am missing something.
>
> Here're the basics:
>
>    1. There will be a Server process (with a "published" address)
>    2. There will be Client processes that may come and go concurrently
>       from anywhere on the network
>    3. Clients will "subscribe" to certain "events" (the events are
>       client-specific)
>    4. A client's events will occur over a "long" period of time
(minutes
>       or longer)
>    5. Publishing all events to all clients and utilizing client-side
>       filtering is not suitable due the network burden
>    6. I would like a solution than can handle heavy loads of event
>       traffic (1000+ messages/sec) if needed
>
> One solution I can imagine is if 0MQ supports "dynamically assigned"
PUB
> sockets where the server can request a new PUB socket from 0MQ and let
> the Port# be auto assigned and query-able. With this, the subscription
> reply can carry the new Port# which the client can then "listen to".
>
> Any thoughts on this from you who are more versed in 0MQ designs?

The only real solution is moving subscriptions up the distribution tree 
so only messages actually needed are not sent to the particular branch.

Jon Dyte started some development to (check the recent discussions on 
the mailing list) achieve this, but of course the more people involved, 
the sooner any outcome...

Martin