[nanomsg] Re: socket ID convention
- From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 4 Jun 2014 17:56:40 -0700
When I created a new protocol for the "STAR" protocol implemented in
mangos, I assigned a large but not value. Specifically I assigned the
value 160 (100 << 4). I consider this a private value, for an experimental
protocol. I do think it would be useful to have some part of the number
space allocated for "local extensions", and another set allocated for
"implementation private extensions". Failing that, I'd be happy to have a
registry. :-)
On Wed, Jun 4, 2014 at 5:15 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
wrote:
> A comment in sock.c reads as follows:
>
> /* If the peer implements a different SP protocol it is not a valid
> peer.
> Checking it here ensures that even if faulty protocol
> implementation
> allows for cross-protocol communication, it will never happen
> in practice. */
> if ((self->socktype->protocol & 0xfff0) != (socktype & 0xfff0))
> return 0;
>
>
> Near as I can tell, this requires the upper 12 bits of any socket ID to
> match, and leaves the lower 4 bits for socket families to implement
> subtypes. Nanomsg’s socket families are then numbered e.g. 0x10, 0x20,
> etc, so that the 12-bit “family part" is a strictly incrementing integer.
> This is all reasonable enough, but I don’t think it’s documented.
>
> As I’m writing new protocols, I’m wondering what is the best way to number
> them, so as to avoid collisions with future nanomsg core types, or future
> third-party socket types. One possibility is to simply pick a high number
> on the theory that you will never get there, but it isn’t clear that
> nanomsg’s use of strictly-incrementing socket families is an actual policy
> as opposed to “what has happened so far”. It also doesn’t explain how to
> avoid collisions with other third-party socket families which may choose an
> overlapping high number. Thirdly in the event that an experimental
> protocol from somebody’s basement actually makes it into core, renumbering
> into the nanomsg system would break binary compatibility with all programs
> that use that protocol.
>
> I’m wondering if it would be a good idea to “assign” or “reserve” socket
> familiy IDs or ranges *a la* the IANA well-known port numbers. In this
> way some expectations are created about how future core protocols will be
> numbered and how third parties should be numbering their protocols.
>
> Drew
>
>
>
>
>
Other related posts:
