Fix protocol description



  • doc/protocol.txt: Replaced type names with architecture independent aliases, fixed 'type' size which is a byte, and recorded that it uses "big endian", or "network byte order" convention.



  • That was fast. Cool. =)


  • developer

    Thanks for contributing and correcting the mistake. However, I think "octet" is more accurate than "byte" because there are systems and programming languages which have a byte size that is not 8 bits (which is why protocol specifications use the term "octet" in most cases). Also, "word" is a synonym for 16 bits todays although the word size is really platform-dependent, while "short" is a language-dependent term and also not accurate. Maybe it would be the best to add that the size of a "word" is two octets (transferred in network byte order, as you have amended) :)



  • Thanks for contributing and correcting the mistake. However, I think
    "octet" is more accurate than "byte" because there are systems and
    programming languages which have a byte size that is not 8 bits (which is
    why protocol specifications use the term "octet" in most cases).

    No way! =)

    Well Wikipedia says there were cases.. Well, in 2000 era I don't think we
    should care. Besides, "octet" has other meanings outside protocol context,
    and "byte" doesn't. Let other people choose a better word for their 6,7 and
    9-bit packs. There is no common variable meaning for the word "byte"
    anymore - http://www.catb.org/jargon/html/B/byte.html

    Also, "word" is a synonym for 16 bits todays although the word size is
    really platform-dependent, while "short" is a language-dependent term and
    also not accurate. Maybe it would be the best to add that the size of a
    "word" is two octets (transferred in network byte order, as you have
    amended) :)

    Dammit. It appears that my brain is too backward compatible and tied to
    x86-64 / WinAPI - http://en.wikipedia.org/wiki/Word_(computer_architecture) I
    now understand why people prefer writing size in bytes rather than using
    "convenient" and "meaningful" names - http://ftlwiki.com/wiki/Continue.sav

    I like the FTL format:

    4 bytes (32bit int)     String length (Ship name)
    

    We can try too:

    9  bytes  (string)   "GfxTablet"
    2  bytes  (int)        version number
    1  byte    (int)

  • developer

    Have a look at RFC 791: »Addresses are fixed length of four octets (32 bits).« Nearly all these specifications use the term "octet", this is why I like it (and it has the 8 bits in the term, as well as "bit" has the 1 bit [binary digit] in its term). So we could write "2 octets (int) Version number", but then it would still be open if this integer is signed or unsigned. Maybe "2 octets (unsigned int) Version number" would be the most accurate description.



  • On Wed, Jan 8, 2014 at 3:38 PM, rfc2822 notifications@github.com wrote:

    Have a look at RFC 791

    September 1981. Not convinced. =)

    http://tools.ietf.org/html/draft-ietf-httpbis-http2-00

    'byte' - 31
    'octet' - 5

    http://tools.ietf.org/html/draft-ietf-httpbis-http2-09

    'byte' - 15
    'octet' - 17

    For me the pattern is rather clear - it looks like people use bytes,
    and think in bytes, but because other guys from 1981 here, and they
    still think in octets, they will rigorously fix all inconsistencies.
    "conservative resistance to change" as they call it. It is easier to
    comply than to oppose them, because it is mostly non-constructive and
    doesn't leave these people happy in the end anyway. =)

    »Addresses are fixed length of four octets (32 bits).« Nearly all these

    specifications use the term "octet", this is why I like it (and it has the
    8 bits in the term, as well as "bit" has the 1 bit [binary digit] in its
    term). So we could write "2 octets (int) Version number", but then it would
    still be open if this integer is signed or unsigned. Maybe "2 octets
    (unsigned int) Version number" would be the most accurate description.

    My personal opinion, is that unless the protocol is bit-based, there is no
    need to complicate the context with details. If you didn't specify
    different size for your bytes, then it is the default. I thought that 16
    bits is the default for words, but you showed me that modern CPUs are still
    using different sizes for this concept. If it will make you feel easier,
    unlike words, the 8-bit size of byte is fixed in international IEC
    80000-13http://en.wikipedia.org/wiki/IEC_80000-13
    standard.

    As for unsigned. I usually work with hex and for me there are three levels
    of data interpretation: byte range (hex), type (int, string, stringz, ...),
    structure (list, tree, index, ...) - I don't usually really care about 2nd
    level interpretation - because it depends on how do you use the data, so
    it's up to implementation. I doubt I'd ever sum or multiply version field,
    so its sign is completely useless for me, but I may want to interpret it as
    a string. In this case the knowledge that its source data in hex form is
    binary digit, is helpful.

    More arguments - if we say that the range of values is 0..65535 - it is
    explicit and obvious. If we say that this is (unsigned short) - it is still
    ambiguous. GfxTablet on Galaxy Note 10.1, for example, returns max 65535/2
    for both coordinates and I suspect that it is a problem with protocol
    description. If there was just ushort, I couldn't rely on that.

    And in the end, I find that I don't like (unsigned int) label because it is
    long, but otherwise it is fine with me.



  • Did I show you what I've built with it? It is here. =) Not very useful
    for mouse control as it appeared, but it is still fun to play with it.

    https://bitbucket.org/techtonik/discovery/src/tip/graphics/gfxtablet/gfxtablet.py?at=default


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.