[PATCH 0 of 1] RFC: SSH transport protocol upgrade

Sune Foldager cryo at cyanite.org
Sun Mar 14 16:25:56 CDT 2010


A few options that could be considered in this patch as well:

a)
The HTTP patch (not posted yet) uses a side channel (http header) to
transfer some information about whether or not to use "weaved mode"
(where stdout/err and data is mixed in the same stream). I included such
a side channel is the new SSH protocol as well (optional data on the
command line after the argument count), but it's not currently used.
It's only one-way, however, from client to server; no side-channel
exists the other way.

I could add that for commands replying with <data count>\n<data> easily,
by including it on the data count line. For the streaming commands, it
could be added by also sending a first line back and reading it on the
client (it could contain 0 or - or another symbol for size, since size
is not known). It's not because we NEED the side channel, but if we
later do, it would not require another protocol change. It would also
bring the low-level features more in sync with HTTP.

b)
To make it easier to extend the protocol later, we could alter the first
line sent from the client to "2 <command> <argc>[ options]\n". The 2
would be the protocol version. Note that this only makes it slightly
easier, as the presense of a number at the front of the line can easily
be distinguished in a later upgrade to the code.

Matt, I'm cc'ing you since protocol changes like these need comments or
at least an ok from you. I'd also like to hear any other comments,
suggestions, criticism etc. from the rest of crew and others who feel
competent. Thanks :)

/Sune


More information about the Mercurial-devel mailing list