On 11/13/2011 09:28 PM, Paul Colomiets wrote: >> Anyone any ideas about how to do this in a backward compatible way btw? >> > Sure, introduce another message flag. Messages that contain it can be > sent at any time, and checked against topology id set as socket > option, each time such message comes in. Also sockets insert them > before first message in any pipe. And for multicast they are just > periodially sent. As it's just sanity check, not security one, we > could live with messages coming from pipes which didn't sent topology > id (but can't actually sent, because I believe messages with reserved > flag set will drop connection).
Makes sense. However, keep in mind the thing that's periodically sent by PGM is a 6 byte MD hash rather than a user-defined string. > Also new implementation that don't set > topology id, should accept any one (so you can upgrade nodes one by > one), eventually this way of using sockets should be deprecated. I've described a fallback mechanism in the SP mailing list: http://groups.google.com/group/sp-discuss-group/msg/e880d1b2c6b02ca4 It should be able solve this problem. > As I've described in SP mailing list, I'm not happy with UUIDs, but if > other way is more complex, I could live with that. (Although, I don't > see a problem of keeping ordinary message with topology id around, to > insert into every new pipe) Again, my rationale for using UUDs is explained in the email mentioned above. Still, to solve the "egg" problem, rather than trying to address the whole "breakfast", the community may settle on sending strings or such. > And please, do both checks: socket type and application's id, it will > help a lot. Yes. The fallback mechanism should solve that. Note that it works because specifying topology ID implies the pattern ID ("NASDAQ stock quotes" implies "PUB/SUB") but not vice versa. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
