[zeromq-dev] Connection setup

[Martin Sustrik]

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