[zeromq-dev] obtain generated identity of socket
justin at affinix.com
Tue Sep 25 00:08:39 CEST 2012
On Monday, September 24, 2012 04:24:06 PM Pieter Hintjens wrote:
> On Mon, Sep 24, 2012 at 2:42 PM, Justin Karneges <justin at affinix.com> wrote:
> > I'm using ROUTER<->ROUTER connections for one-way communication. How can
> > the sending peers identify the destination peers?
> The only sane way I found was to use the server endpoints as agreed
> identities, i.e. if you're binding to 192.168.55.131:5555, then use
> that as your identity when connecting. This lets the other router talk
> to you.
Makes sense. I've currently made it work by generating a UUID (in my app code)
and using that as the identity. This identity is sent using a separate socket
to the client.
> But mostly router-to-router seems like a bad pattern. I'd rather do
> two connections, one dealer-router in each direction, so each peer
> plays "server" and "client" cleanly. Just simpler to understand.
Here's my use-case; maybe you can critique it: I want to send a stream of data
to a server instance (of which there may be multiple), and I want to ensure
all the messages for a given stream go to the same server.
The server uses 3 sockets:
in: PULL socket, for retrieving "start" requests
out: PUB socket, for sending notifications (ignore why this is PUB, for now)
in_stream: ROUTER socket, for retrieving "append" messages. this socket is
given an explicit identity.
Protocol flow goes like this:
1) client pushes a "start" request that gets picked up by one of the server
2) server pubs a "clear to send" response that includes a reply address
field, containing the value of the in_stream identity
3) client sends a series of messages to in_stream, addressed using the reply
In other words, PUSH deals to an arbitrary server, but once the server acks
the request, the client locks on to that server and sends the remainder of the
stream specifically to that server. For flow control, the server regularly
grants credits to the client via the pub socket.
The client writing to in_stream should use a ROUTER socket for itself, since
it is using the enveloped addressing that requires routing. The server, on the
other hand, could be DEALER or ROUTER, I suppose. Both terms seem misleading
for a socket that never gets written to, but ROUTER seemed slightly less so as
it is the most raw. Maybe it should be possible to connect ROUTER to PULL? :)
More information about the zeromq-dev