On Mon, Feb 03, 2020 at 09:22:16PM -0700, David Fifield wrote:
My plan is to reserve a distinguished static token (64-bit value) and have the client send that at the beginning of the stream, before its ClientID, to indicate that it uses Turbo Tunnel features.
[...] Here's a commit that restores compatibility with current Snowflake clients. It works the way I described: the client sends a magic token at the beginning, one that non???Turbo Tunnel clients will never send. [...] The addition of a magic token prefix very slightly constrains traffic shaping.
Hi David!
Awesome news about the turbotunnel integration. I've been pondering the backward compatibility thing ever since your first mail. Here are two hopefully useful thoughts. Let me know if they are misunderstanding things in some way.
(A) An extra 8 bytes for every new or resumed flow, forever, is kind of sad. But it doesn't have to be forever: in the future, once the old Snowflakes that don't send that static token are long gone, we can stop requiring the token. (That is, if clients send it, that's fine, we can recognize and strip it. And if they don't send it, that's fine too.)
(B) Another approach to backward compatibility might be to leave the old Snowflake bridge up, not knowing what a turbotunnel is, and to put up a new one nearby or somewhere else that expects turbotunnel connections. Then after a few releases of Tor Browser, we could shut down the old one and move on.
Approach 'B' would have been best to suggest in between your first mail and your second one. Oops. :) Better late than never maybe.
Thanks! --Roger