[zeromq-dev] Connection setup
B.Candler at pobox.com
Wed Apr 21 19:37:25 CEST 2010
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?
> >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
> 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.
> >(*) 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?
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.
More information about the zeromq-dev