Authorization

The version exchange and authorization phase of protocol is quite diffrent from the rest of it. It doesn't use packets, just plain text and raw data. Uppon connection server sends string:

     Yserver <major version>.<minor version> <actuall software>\n
    
where major and minor version number are always 0.0 at this moment. <actuall software> can be any string, up to 40 characters without \n (ascii 10) inside. It is not used for anything important inside the protocol, but it might be logged. The string is followed by \n (ascii 10). The entire string cannot be longer then 100 bytes.

Client is expected to send string:

     Yclient <major version>.<minor version> <actuall software>\n
    
everything as above.

Then, when version mataches [[[TODO: what if not?]]] authorization process is started. Both client and server send 256 byte random cookie (as raw bytes). The other side is assumed to compute MD5 hash of 256 authority bytes and 256 bytes of cookie (in this order) and send it back. So client computes MD5 hash of authority and server-generated cookie it recived, and sends it back to the server, server also computes MD5 hash of authority and client-generated cookie, and compares it with what client supplaied. Authority bytes are generated upon server startup. It's up to the end user to supply them somehow to the client. (suggested way is that server writes authority bytes to .Yauthority file in user's home directory, and client reads it). The MD5 hash is also send as raw data (16 bytes). When MD5s computed on client and server side doesn't match, the connection is closed, by side wich has detected unauthorized access. After this authorization process has successfully finished client-generated cookie is no longer needed, and might be destroyed. Server-genrated cookie along with authority bytes is used to generate keys for cryptography. [[[FIXME: this is confusing]]]

Then server sends list of supported features, each feature is follewed by comma and entire list is follwed by \n. Feature names can contains [a-z0-9_] characters. The only feature required by this version of protocol is packet connection, other are optional, but server implementaion is recommended to support arcfour encryption and zlib compression. Features defined at this point are:

Client then send comma-separted, \n terminated list of features it wants to use. Client shall specify pkt_conn there, otherwise bad things (tm) can happen :^) And, seriously, this is hack to implement some other connection schame in future versions.

A word about encryption. Arcfour (or rc4, © RSA Corp. :) is simplest encryption algorithm I've ever seen, while it's still secure and fast. Key for this, and possibly other symmetric ciphers, that will be added in future, are derived from .Yauthority and server-generated cookie. Key used to encrypt connection from client to server is done from even bytes of concated authority and cookie. Key used to encrypt connection otherway around, is made from odd bytes. So, if buf[512] contains 256 bytes of authority and 256 bytes of cookie, then, in client, key used to write is made from buf[0], buf[2], buf[4], buf[6]... etc, and key used to read is made from buf[1], buf[3], buf[5], ...

Zlib compression. Two zlib state buffers are maintained throughout the connection. If it's enabled, entire communication is compressed and treated as stream. Client and server flushes connection whenever they need to. I.e. when client sends some call that needs reply to server, then it should flush the connection. And server, when it sends reply should also. But when we send void calls to sync buffers, only one flush at the end is required.

Note that if both encryption and zlib are in use, data first need to be compressed, and after that encrypted.