On Mon, Jun 24, 2013 at 10:19 PM, Martin Sustrik<sustrik@xxxxxxxxxx> wrote:
In other words, if you want a protocol that's similar to PUB/SUB but differs
slightly from it, define a new SP protocol with different protocol ID.
Internally, you can of course re-use the PUB/SUB implementation if you find
that useful.
I was imagining a protocol that could support SUB as a subset, as a
separate explicit mode, say to handle older clients, so when it gets a
SUB trying to attach it attaches it in backwards compatibility mode so
as far as it knows it's connected to a PUB. Maybe I'm overthinking it.
You'll have the same problem with textual names. The words that make sense
as socket types are rather limited in number so you are going to get
clashes.
In either case you need a central authority to keep the list of existing
protocols/socket types. The obvious choice for that is IANA. (See, e.g. the
list of TCP ports managed by IANA.) Till then we can just keep the table on
the web page somewhere.
You have the same problems, just less of them and they're easier to
resolve--or at least less irksome. I just worry it gets messy with
multiple 3rd party protocols with multiple versions. There are only so
many useful protocols and simple enough that few versions will be
needed so perhaps I'm imagining problems.
I think there's an "endpoint" object missing. So, when you do "nn_bind
("tcp://127.0.0.1:5555") an endpoint is created, which, itself, has a list
of connections.
That's what I was referring to as network connections, but maybe I'm
misunderstanding something.
