Open Kittyfisto opened 7 years ago
This task shall help solve #12 and #32.
The structure should contain a protocol version field. Which currently needs to be kept track of manually. An endpoint may support multiple versions, but won't in the beginning.
This introduction of this feature will break backwards compatibility.
This task will also solve #11.
SocketEndPoint shall always use a binary serializer for the connection handshake and then switch to the serializer the handshake has negotiated.
Future (web) endpoint implementations might have a different approach.
The implementation of this issue should make sure to be extensible in the future, so that #53 can be implemented. As such, the Handshake should take into account that any of the two EndPoints might not be aware that feature X has been introduced:
Suppose a client tries to establish a connection with a server: The client tells the server that it supports compression. The server uses an older version of SharpRemote and thus is unaware of the compression feature, it tells the client of its supported features (which does not include compression). The client must then not use compression. To generalize this behaviour both client and server must negotiate on the set of features which are supported by the server and client.
How can the handshake also negotiate which serializers can be used, given that backwards incompatible changes to them might still be introduced after release?
It might be necessary to also track and send a serializers version with the handshake.
The current handshake between client and server is a bit basic and doesn't exchange a version info field or any kind of exchangeable structure. This makes introducing optional features (such as choosing a serializer, or running compression) impossible.
The goal of this task is to create an extensible structure which is exchanged between server and client to negotiate protocol version and used serializer.
This part should probably already be using SslStream, when encryption is used (see #35).