Fix protocol description

0

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.

0

That was fast. Cool. 😃

0

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

Temporal relations are not necessarily causal relations.

0

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

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.

Temporal relations are not necessarily causal relations.

0

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.

0

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.