Fix protocol description #46

Merged
merged 1 commit into from Jan 6, 2014

Conversation

Projects
None yet
2 participants
Contributor

techtonik commented Jan 6, 2014

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.

@techtonik techtonik 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.
51d862c

rfc2822 merged commit ff865c2 into rfc2822:master Jan 6, 2014

Contributor

techtonik commented Jan 7, 2014

That was fast. Cool. =)

Owner

rfc2822 commented Jan 7, 2014

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

Contributor

techtonik commented Jan 7, 2014

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

rfc2822 commented Jan 8, 2014

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.

Contributor

techtonik commented Jan 8, 2014

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.

Contributor

techtonik commented Jan 8, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment