test suite "client protocols" don't speak the client protocol

[meejah]

The test-suite contains implementations of the client-side protocol.

However, they don't actually implement the whole protocol. There's a secondary "handshake" in the real transit protocols that send part of the key to the other side.

When testingting TCP<-->TCP messaging, this is fine -- because that's part of the "client to client" messaging and so arguably if expected bytes arrive then all is well.

However, that part of the protocol is still using "line ending" framing. That is, the switch to "encrypted record pipe" with length-prefixed blobs doesn't happen until after this next handshake. When interoperating between a WebSocket client and TCP client, we need to correctly frame / de-frame those bits too and so the test implementations need to speak the "real" protocol to get to the "bulk data transfer" portion properly.

[piegamesde]

This is a tricky one, especially because the relay should also support Dilation which as a different handshake. It's no big deal we can just implement both, but I'd really like to see a solution where we can have a server implementation that is agnostic of the underlying "protocol".

[meejah]

The Transit can either translate the framing, or not.

Since we chose "translate" we thus have to understand enough of the protocol to get to the point where the framing method switches. That's after both handshakes.

[meejah]

That said, yes we will want to support Dilation as well of course.

Luckily the handshakes are pretty similar and both use the same double-newline framing. The relay handshake is identical.

[piegamesde]

Honestly, I am slightly reconsidering my position on the "translate the framing" problem due to this. Maybe having a redundant length field and a bit more complexity on the client implementation (if they support WS at all) is the lesser evil after all.

[meejah]

That would mean every client (that supports non-TCP) has to understand both kinds of framing (newline-delimited and length-prefixed).

It certainly makes the Transit more-straightforward, of course.

In some ways it might make the clients easier in that if they followed a nice sans-IO model of implementing the transit (or Dilation) protocol they simply feed all bytes they get (whether that's from TCP or WebSocket or RFC2549) into their protocol machine.

At this point, we could change the Dilation handshake (although I don't see how that would help much). We could also change how we specify the WebSocket support since that isn't released yet.

This particular ticket is still valid, though (the relay handshake exists, and will continue to exist): the question becomes where the knowledge about the secondary handshake and subsequent framing "lives".

[piegamesde]

Whichever way I look at it, if we want to keep the current behavior and a simple relay server then clients will have to implement some logic to extract framed messages from a stream of differently framed messages. Be it with a sans-IO state machine as you described or using some adapter like Wormhole William's websocket.NetConn, does not matter. I am not sure whether this is better or worse than having the relay inspecting and re-framing every message.

If I could change one thing to the Dilation handshake, then I'd like to have the initial message prefixed with the length (I think it would render to "\0\0\0-" or "-\0\0\0" as ASCII string). With that, all Dilation handshake messages would have the normal framing and there would be no need anymore to do line parsing. I'd really like to see that change, but admittedly it won't help much with our current issue.

[meejah]

I am not sure whether this is better or worse than having the relay inspecting and re-framing every message.

The messages it has to "inspect" are just those first two handshakes (because they're framed differently). After that, everything is straightforward.

However, it is a lot more complex on the transit side to do that part correctly (vs. switching to "byte shuffling" immediately after the relay-handshake). @vu3rdd and I have been having the same doubts (i.e. "is this complexity worth anything?").

(Agree consistent framing for all messages would be good).

[meejah]

p.s. "sans-io" isn't necessarily tied to state-machines; it basically just means properly separating the I/O from the parsing etc logic. (It could be that the Go implementation qualifies here, if it uses the same implementation to produce/consume data to TCP vs WebSocket -- I don't know it well enough)