Developers.Idea.PacketDesign.Notes: Difference between revisions
(Importing page from Tikiwiki) |
m (1 revision) |
Latest revision as of 20:09, 20 June 2009
the handshake has this same design philosophy, except with some changes -the order of the lines don't matter -there is additional text formatting on the line -you can only have text, no binary blocks -a blank line ends
so how are they different from http headers -all lowercase -the first line is just z. -a name with several values is like this
<source lang="c"> packet p p2 o o2 o3 u u2 </source>
see, we can split on space, trim everything, and then read it as an array
-features are on a line all by themselves, and don't have a value, they are just a name
<source lang="c"> compress </source>
this means the client can read and write compressed data. if it can and sees its neighbour say it, well then it turns it on in both directions. make it that simple. kill this default: 0.1 versioning thing. no one will ever make it to 0.2. and if you did, well then the feature name would be compress2 just like a new packet name
-lines are terminated with \0, not \r\n
-to be cool and brief and cryptic, the first line is always just z. here are some headers
<source lang="c"> z packet p p2 p3 o o2 o3 compress ip aabbccddeeee </source>
so, to detect this kind of communication, the handshake code looks for a lowercase ascii z followed by the 0 byte.