[zeromq-dev] obtain generated identity of socket

[Justin Karneges]

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 
instances
  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 
address

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? :)

Justin