[nanomsg] Re: socket ID convention
- From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 4 Jun 2014 23:16:53 -0700
Works for me too.
On Wed, Jun 4, 2014 at 10:55 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
wrote:
> OK by me
> On Jun 5, 2014, at 12:39 AM, Martin Sustrik <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
> <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 <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
> <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:
