On Monday, September 24, 2012 04:24:06 PM Pieter Hintjens wrote: > On Mon, Sep 24, 2012 at 2:42 PM, Justin Karneges <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
