Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Include a magic number in the TCP stream handshake #245
In principle each timely instance should be talking to the same binaries, which we could also try to check. I wonder if it makes sense to try and generate a magic number at build time, to confirm that the binaries are talking to similar instances of themselves... ?
Indeed it would! I was planning to do that at a higher layer of the stack (i.e., Material), since folks often frown upon doing anything too magical in a library, and Material will need to do its own version check anyway. But there's no harm in the redundancy, if you think its worth doing in Timely too.
Did you mean generating a magic number in build time in addition to or instead of the permafixed magic number? IMO its worth having both. The permafixed magic number reduces the burden on the TCP multiplexer, since it can do a blind equality comparison on the first u64 in the stream. By contrast, the PostgreSQL wire protocol, annoyingly starts a connection with one of five possible versions, with the possibility of expansion at any point; HTTP starts with one of "GET"/"HEAD"/"OPTIONS"/"POST"/"PUT'/....
You could argue that perhaps we shouldn't be multiplexing multiple protocols over the same port—that is what ports are for, after all—and you would be right, but experience has shown that when one application needs to speak multiple protocols, it is much easier on everyone involved if you can stuff all the protocols into one port. (Specifically, CockroachDB multiplexes GRPC and pgwire on 26257, but has to offload HTTP to another port for performance reasons; the separate HTTP port was a real nuisance and the multiplexed 26257 port was delightful and never caused any problems.)