On 11/05/2011 03:32 PM, Pieter Hintjens wrote: > On Sat, Nov 5, 2011 at 1:32 PM, Martin Sustrik<[email protected]> wrote: > >> If you have any concrete improvement in mind, feel free to propose it. > > There are a set of things we wanted to add to the protocol, such as > socket type checking.
Sorry for the delay. This one is a complex problem so let me share some random half-baked thoughts about it: The obvious solution is that each peer sends its socket type to the other peer, which in turn verifies it and drops the connection if it is incompatible with the advertised socket type. Now, consider that this kind of mechanism is needed at at least three layers of the stack: 1. TCP. Identifying TCP services such as SMTP vs. SSH vs. HTTP. This mechanism exists => TCP ports. 2. 0MQ. Identifying different 0MQ services such as PUB/SUB vs. REQ/REP vs. PUSH/PULL. 3. Application. Identifying different application level services (topologies). For example, stock quote distribution vs. video chat distribution. The above problem can be solved in two basic ways: either use a separate "type negotiation" mechanism at each level, or try to unify it in some way. The first option is pretty obvious and easy to implement. However, there are several problems with it: a. It doesn't solve the problem of non-0MQ application (SMTP or whatever) connecting to 0MQ application (pt 1 above). b. It can be done on 0MQ level (pt 2) but it's not clear how to do it on the application level (pt 3) especially when the pattern in question is unidirectional or unreliable. The only option available seems to move application level type-checking to 0MQ which in turn suffers of the other problems mentioned in this list. c. It doesn't play well with unidirectional or unreliable transports. To do type checking we need to pass the type in both directions and in a reliable way. d. The type checking mechanism is not a generic feature. It's different for each transport protocol. Type checking for TCP is different from type checking for SCTP as the two cannot speak together anyway. e. Different messaging patterns are orthogonal non-intersecting protocols that happen to be bundled in a single library (libzmq). You can think of it as say a single library providing TCP, UDP and SCTP support. However, type checking is a universal feature that cuts across all these protocols. Intuitive reaction of a protocol designer would be to move it to a common underlying layer thus (TCP and friends). The above leads us to a second possible solution, which is providing a unified, transport-agnostic type checking system. The idea of this solution is to provide the type checking in the single layer, namely the transport layer which is common to all the patterns. In practical terms it means, for example, using TCP ports to identify particular service on TCP, 0MQ and application level. The second component of the solution should be a system for mapping the high-layer type (topology, e.g. "NASDAQ stock quotes" to lower-layer types (i.e. PUB/SUB on 0MQ level and port 5555 on TCP level). This second solution makes more sense IMHO, but, at the same time, requires much more work and experimentation to get it done. Uh. That was long... Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
