-
Notifications
You must be signed in to change notification settings - Fork 133
Protocol v5
Ideas for version 3.0
Version 3.0 will be the next chance to make big changes to the protocol.
Websockets could be used instead of a plain TCP connections.
The STARTTLS login command would be unnecessary. Instead, the use of encryption would decided by selecting either using either the ws or wss scheme.
MSG_PING would also be unnecessary, since keep-alive functionality is built-in to the websocket protocol.
Pros:
- Makes it possible to implement native web clients
- Standard extension for compression
Cons:
- Increased overhead due to bigger frame headers (might be significant for small messages)
- Compression is per-message only
Compromise: maybe support both plain TCP and Websocket connections simultaneously?
Drawpile presently does not verify certificates against root CAs, but is instead designed to be used with self signed certificates. This is because when SSL support was added, Let's Encrypt didn't exist yet, so free SSL certs were not available.
Drawpile should utilize PKI the normal way, but still support certificate pinning too for self-signed certs.
The option to not upgrade the connection to SSL (when the server is configured with a cert) should be removed. Support for SSL is always available now.
The MSG_COMMAND command should use JSON-RPC. If websockets are used, all COMMAND type messages could be sent via the text channel.
Pros:
- Simpler ID assignment (just an autoinc)
- No ID reuse
Cons:
- Message header is 1 byte longer
- Session can run out of IDs (unlikely though, at an average rate of one login per second (each with a unique username,) it takes over 18 hours to exhaust all IDs.)
- Layer and Annotation IDs must be upgraded to 32 bits too, since the first half is the ID of the user who created them.
A new architecture style should be made possible: users connect to a greeter server which redirects them to the actual session servers. This should all be transparent; the UX should not differ from the current single server approach.
Example login flow:
- User connects to pub.drawpile.net
- User authenticates
- Server sends a list of sessions. At least some of which are identified by URLs and might be hosted on a different port or on a different physical server entirely.
- User chooses a session that is hosted on a different server.
- The client disconnects from the greeter server and makes a new connection to the session server. This should happen transparently. Included with the session URL was an authentication token that allows the client to handle the authentication without prompting the user again.
Hosting works similarly. The client sends the host command and, if the newly created session runs on a different server, the server responds with the URL of the session.
An authentication token, similar to the ext-auth one, is used. Since all session servers must be affiliated with the greeter server, a shared secret can be used to sign the token. The secret can, and should, be a random key unique to each session server instantiation.
Login redirects enable a number of nice features:
- Makes it possible to run each session in a separate server instance. Especially important for smart-servers, which are heavier and more likely to crash
- Session announcements will still point directly to the session servers -- no need to go through the greeter (consequently, session servers must still support the full login flow.)
- Server instances do no need to run on the same physical server
- Possible to update server version without disrupting existing sessions.
- Greeter server does not have to be written in C++
Merge Chat and PrivateChat messages: these are separate only for backward compatibility reasons.