Protocol versioning (feature request with potential implementation)

[avieth]

A candidate implementation of protocol versioning. Here's how it works:

Versionless part of the protocol:

• When A connects to B it always sends a Word32 version identifier followed by a Word32 giving the length of remaining data (presumably version-specific handshake data).
• B can request a different version by sending ConnectionRequestUnsupportedVersion followed by a Word32 indicating the version which B would prefer to use. Since it has the length of the remaining data, it can then read and discard the rest of the data sent by A.
• A can try again using B's preferred version, or abandon the connection if it doesn't support that version.

If B accepts the version number, then the rest of the interaction proceeds according to that version.

Currently there is only version 0x00000000. Any connection with a different version number will be rejected as unsupported, and any rejected connection attempt will abandoned because this version of nt-tcp supports only 0x00000000.

It's important to note that there's minimal performance penalty for the typical Cloud Haskell use case, where every peer runs the same version. The versionless part of the protocol is optimistic: the connecting peer assumes its peer will be able to handle its version, and extra round trips are imposed only if the peer needs a downgrade/upgrade.

Thoughts?

[avieth]

followed by a Word32 giving the length of remaining data (presumably version-specific handshake data).

There would have to be a sensible maximum length here.

[avieth]

Is there a multi-part version scheme here or not?

No decision about the versioning scheme has been made, only the size of the version identifier (32 bits).

Should we start from version 0? We're already changing it! Perhaps clearer to call the new version v1.

Doesn't matter to me. How about we do multi-part and go with 0x00000001 (or 0.0.0.1).

I'm slightly unclear if certain things are being moved around or also changed. Might be clearer if we split the patch in two: first moves things around, second changes behaviour.

Yes there's a lot of movement. I'll split it up into 2 commits.

[avieth]

@dcoutts 6fbb642bb567ba1b0930b676dbd779764175182f is just code movement, 2ba08264b9cb8c615e5b9993cdf4fc3d5a2c9506 is the actual versioning implementation.

[avieth]

Included the commit from #60 in here to make the tests pass.