No, using different port numbers will not work the way you feel.
aSubTypeSOCKET.setsockopt( zmq.SUBSCRIBE, aLeftMatchTopicFILTERasSTRING )
aSubTypeSOCKET.setsockopt( zmq.SUBSCRIBE, anotherTopicFILTERasSTRING )
...
aSubTypeSOCKET.setsockopt( zmq.UNSUBSCRIBE, aLeftMatchTopicFILTERasSTRING )
...
aSubTypeSOCKET.setsockopt( zmq.SUBSCRIBE, yetAnotherTopicFILTERasSTRING )
is the standard mechanism how to setup Topic-filter matching condition(s) to effectively work with.
Multiple connect()
-s are possible, but
aSubTypeSOCKET.connect( "tcp://123.123.123.123:12345" )
aSubTypeSOCKET.connect( "tcp://123.123.123.123:23456" )
aSubTypeSOCKET.connect( "tcp://123.123.123.123:34567" )
will make aSubTypeSOCKET
indeed .connect()
-ed to several port-numbers, but the sender side yet decides, if a subscription "mechanics" will deliver a content "specialisation" that you might have expected to use instead of the common Topic-filter(s) subscribed to using .setsockopt()
.
Next, if multiple .connect()
-ed PUB
-s deliver messages, the SUB
-side is getting these in through an incoming "routing" strategy, by a "Fair-queued" manner, so the SUB
-side will have to turn and check the round-robin wheel a complete turn around, just to see, if any present/not-present and any non-empty subscription Topic-filter setup will apply to all PUB
-sides symmetrically, similarly the first empty-string Topic-filter will "unblock" / "short-cut" all senders to deliver any messages from all PUB
-access-nodes.
I would not call that any simpler.
APPs typically build a complex signalling/messaging plane
an indeed as persistent as possible infrastructure, where many socket-Access-Points do .bind() / .connect()
to many individual access-point addresses, as desired for, using some mix of many transport-classes available { inproc:// | ipc:// | tcp:// | pgm:// | epgm:// | vmci:// }
.
This is one of many strengths the designs, based on ZeroMQ, can and do enjoy.