Hi Martin, On Tue, Nov 15, 2011 at 11:19 AM, Martin Sustrik <sust...@250bpm.com> wrote: > 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. > It's inconvenient. Does sending topology id as ordinary message feel too wrong?
>> 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. > I'm not sure I understand fallback. >> 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. > Will answer there. > 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. > Well the problem I'm trying to solve is following. We have a device having two ports one for pub and one for sub, they are called equally either by intention or by coincidence. Then connecting pub to pub will emit no error, which is strange. So if we would not implement both checks you will need to invent a name for each socket rather than each topology. Checking both also helps catching programming errors. Again, in zerogw in some places we have a choice between pub and push, and if you configure names right, that doesn't means you have configured types correctly. -- Paul _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
