Hi Martin, On Sat, Nov 12, 2011 at 9:16 AM, Martin Sustrik <[email protected]> wrote: > On 11/12/2011 08:15 AM, Martin Sustrik wrote: > >> 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. > > 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). 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. 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) And please, do both checks: socket type and application's id, it will help a lot. -- Paul _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
