Brian, > On Wed, Apr 21, 2010 at 02:30:03PM +0200, Martin Sustrik wrote: >>> There is an existing initial handshake, which at the moment does nothing >>> more than exchange peer identities (*). Maybe it should also say "I'm a >>> REQ" or "I'm a P2P"? Then the connection could be dropped if it was an >>> inappropriate peer. >> That would work as long as you are using bi-directional transport >> such as TCP. How should the problem be solved say with PGM which is >> inherently uni-directional and moreover receivers can join the feed >> at any point? > > I guess the "initial handshake" is missing entirely in that case. Perhaps > only the PUB-SUB pattern makes sense over this transport anyway?
Presumably. >>> Extending this further, the client could ask >>> to talk to a named service, so that multiple distinct services could be >>> served from the same port. >> That's a tempting solution as it provides a way to tunnel all the >> traffic throught a single open port in a corporate firewall. >> >> However, it doesn't allow for systematic traffic shaping and network >> monitoring. >> >> Moreover, it can be argued from the security point of view that if >> there's a new feed/service crossing the corporate firewall, passing >> the audit/approval process to open a new port is exactly the thing >> that should be done. > > Ultimately firewalls should be extended to support the application protocols > passing through. But to support existing firewalls you could start with an > initial HTTP exchange, and then switch to a binary protocol afterwards, just > as Websockets does. > > Come to think of it, Websockets is almost identical to 0MQ at the wire > level: simple frames of opaque data. > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 > >>> (*) I can't see how the local identity is set, or the remote identity is >>> read, in the current API. Have I missed something? >> It's about resources. Say you want the queue to hold at most 1000 >> messages from each client. If client sends 1000 messages, then >> disconnects, reconnect and sends 1000 messages more, there are 2000 >> messages from the same client in the queue. The server has no way to >> tell whether it's the same client or a new one. That's what identity >> is for. > > What I meant was, in the current C API, is there a way to set your own > client ID to be sent to the peer? And how can you learn the client ID of a > message you receive? Or if you can't, what is it used for? You can set you identity via ZMQ_IDENTITY socket option. Identities are used strictly to make 0MQ infrastructure know that process X is the same as process Y after it have been restarted. Identities are not attached to messages. You can do that on app level if you need it. > Given that some settings are negotiated at the beginning of a TCP > connection, you could put them into a buffer associated with that > connection. Then a recv() could pass a pointer to that (const) buffer. Applications using 0MQ should be agnostic about the source/destination of the message. If you need such a connection-based behaviour you should use Berkeley sockets instead. 0MQ is message-oriented, not connection-oriented. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
