[nanomsg] Re: socket ID convention
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 5 Jun 2014 01:23:39 -0500
What’s the criteria for “deserves a formally allocated ID” ?
On Jun 5, 2014, at 1:22 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Signed PGP part
> OK, let me write the doc.
>
> I'll pull in the protocols from nanomsg. Then I'll allocate a chunk of
> IDs for experimental use.
>
> Once you feel your protocol deserves a formally allocated ID, just
> patch the document.
>
> Martin
>
> On 05/06/14 08:16, Garrett D'Amore wrote:
> > Works for me too.
> >
> >
> > On Wed, Jun 4, 2014 at 10:55 PM, Drew Crawford
> > <drew@xxxxxxxxxxxxxxxxxx <mailto:drew@xxxxxxxxxxxxxxxxxx>> wrote:
> >
> > OK by me On Jun 5, 2014, at 12:39 AM, Martin Sustrik
> > <sustrik@xxxxxxxxxx <mailto:sustrik@xxxxxxxxxx>> wrote:
> >
> >> Signed PGP part Let's have a registry so that people don't step
> >> on each other toes.
> >>
> >> What about having a document in nanomsg/rfc directory?
> >>
> >> Martin
> >>
> >> On 05/06/14 04:32, Garrett D'Amore wrote:
> >>> Works for me. And yes, I meant 1600. :-)
> >>>
> >>>
> >>> On Wed, Jun 4, 2014 at 7:30 PM, Drew Crawford
> >>> <drew@xxxxxxxxxxxxxxxxxx <mailto:drew@xxxxxxxxxxxxxxxxxx>
> >> <mailto:drew@xxxxxxxxxxxxxxxxxx>> wrote:
> >>>
> >>>> 160 (100 << 4)
> >>>
> >>> I think you mean 1600?
> >>>
> >>> Following your lead, I will start numbering at 104 << 4,
> >>> a.k.a. 1664. Blocks of 4 families feel about right to me, as
> >>> they are small enough to not be much of the available space
> >>> (0.02%) but large enough to fit most nanomsg extensions I can
> >>> think of (and failing that, just request more blocks).
> >>>
> >>> Starting from those premises the map would look like 0-1599 -
> >>> reserved for nanomsg 1600-1663 - reserved for mangos 1664-1727
> >>> - reserved by me 1728-65535 - available
> >>>
> >>> The other possibility I see is just to declare some area
> >>> “available for private use” but it seems likely to me that
> >>> everybody doing experiments would start their numbering at the
> >>> first value in the private area, so it is probably better to
> >>> coordinate something, even informally, than have guaranteed
> >>> collisions in the private block.
> >>>
> >>> Drew
> >>>
> >>>
> >>>
> >>>
> >>> On Jun 4, 2014, at 7:56 PM, Garrett D'Amore
> >>> <garrett@xxxxxxxxxx
> >> <mailto:garrett@xxxxxxxxxx>
> >>> <mailto:garrett@xxxxxxxxxx>> wrote:
> >>>
> >>>> 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 <mailto:drew@xxxxxxxxxxxxxxxxxx>
> >> <mailto: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:
