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