[nanomsg] Re: socket ID convention

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Thu, 05 Jun 2014 08:22:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTkAyHAAoJENTpVjxCNN9Yo/QIAIpMUdpJa6b1M0qbUPBokGdz
Bw5BmZaMsQ+dT/JaNcVtn+gVqE8H0DmFS5oaejdCS2nT9ubNqe/QqluILJXnVKwj
RM3VliCkEtMWXVsK4nH2iRzNi4sELL5pw1nba41rvjLJxujCRD9J2vI4Y0xm9MMV
Md2mdThFteMOj64oIMdnMvyTXeZZIw75//GhmuvTl2uq8Ai2hktICC4oZlP9Rl98
7T700CGIOa0oLSd6fo6/eL7XZ7PfC9sNCcdL3GpE/8VhezedSnF4uti8/oX40I3b
duFU/H/j/yXQIXqo99co/8+SoMTHvrgtdoU3xlWsSTeTurr62qVdkRwnWQkz3Gk=
=oMD+
-----END PGP SIGNATURE-----

Other related posts: