[nanomsg] Re: socket ID convention
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 05 Jun 2014 07:39:52 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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>> 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>> 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>>
>> 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
>>
>>
>>
>>
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTkAKjAAoJENTpVjxCNN9Y6R8H/RnOTmjxe1wbTqfaGoTNcuCV
CITgh5VSIeyP9e+g1yzag0TyL1UvO2uyJFAY2yfpQ6ql7pMUmNibWYyRyOrcm8wR
UmSYbJFyHRZzlZvgVW9eIgfF+9QI79PivJlcl3YPIlkNj+tzMFoKSC/9fuX8f2b4
GiCtdsvXlEJZH1WUvmCXteetgp4v0ViR+t+WPO6lnNrsNx5yQHrM62HoIdP7xq5x
XsLC/FgQE5ge6rOdTgv2gL4Jm4CZBB2CYnKkTJu/Ax42zGoQzlulvARxth7hVfr2
Lt5ejb278s6ShzbSl+r7DqklqRBPhXt2HV3clx4P5FO5prz80Y4E5J5Uuzzzx54=
=voDT
-----END PGP SIGNATURE-----
Other related posts:
