[nanomsg] Re: socket ID convention
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 5 Jun 2014 01:49:25 -0500
I’m not sure that the criteria, literally applied, makes any sense
By the time the software is distributed, it is too late to apply for a formal
ID, because binary compatibility is a concern. Whereas an ID cannot be
obtained prior to distribution. Bit of a catch-22 there.
It’s also important to clarify if “made available for use” counts as
distribution (as distinct from, say, *actually deployed*). An author may not
even know whether other entities use the protocol if the extent of their
distribution activities is to quietly publish a repo on GitHub.
My recommendation would be
To allocate a block to core
To allocate an experimental block, with the understanding that literally
everything here will collide and so it’s not suitable for distribution of any
kind
To allocate a small number of IDs basically on demand, but with the
understanding that there should be a bona fide intent to use. And if in the
future somebody asks if they’re still in use and receives no response, they can
be reclaimed after some reasonable period.
On Jun 5, 2014, at 1:30 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
> I contend that the criteria should be any ID that is part of software
> distributed to more than one entity. I'd recommend a piece of the space
> still be reserved for "local experimental use" (or "locally administered").
>
> In other words if the code is stable enough for you to redistribute to anyone
> (regardless of binary or source form), then its probably useful to reserve a
> global id to prevent collisions.
>
>
> On Wed, Jun 4, 2014 at 11:23 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
> wrote:
> 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:
