Hi all, I guess there are two separate problems there. As Pieter puts it there's a "breakfast" problem and the "egg" problem.
We have no good idea how to solve the "breakfast" problem, so let's move the "breakfast" discussion to the SP mailing list and focus on the "egg" here, namely on what kind of type checking we are able to provide today and in a backward compatible way. One additional requirement, IMO, is not to expose the functionality directly at the API level. That way, if the mechanism is improved or changed in the future, it won't cause existing applications to be re-written. As I've mentioned in my previous email there are 3 different layers involved: TCP, 0MQ and Application. We are definitely able to provide type checking at 0MQ level today - just send a socket type ID to the peer and check the peer's type ID for compatibility (PUB with SUB, REQ with REP etc.) The TCP and Application level type checking is not that clear. However, we can pass opaque data to the peer instead of a well-defined socket type ID. That way the mechanism can be used for additional type checking if needed. At the moment I would say sending an UUID representing the socket type would be the best. Being a 128-bit random BLOB, there's no realistic chance that a non-0MQ connection would begin with exactly the same 128 bits by accident. Which solves the type checking at TCP level in a way. As Ilja and Paul say, application-level type checking is more important to the users than either TCP or 0MQ-level type checking. I believe that the UUID can be used to identify a topology (Application level type checking) in the future. At least in theory, that is. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
