[mosh-devel] Agent forwarding in Mosh

Timo J. Rinne tri at iki.fi
Sun May 12 15:30:27 EDT 2013


Hi All

After maybe three times the effort I estimated before reading the code,
I finally got Mosh to forward agent connections.  The generic
out-of-band transport mechanism and agent forwarding implemented on top
of that total to some 1500 lines of code but I am happy to say that I
was able to keep changes in code outside those modules quite small.

Some release notes:

- Out-of-band transport mechanism is quite rudimentary but it does
support three different operating modes for different needs.
1) datagram: packet is sent once and it may or may not arrive and may
get duplicated or out of order. However, if it arrives, it complete and
has same integrity guarangee as mosh traffic generally.
2) reliable datagram: all packets are sent and guaranteed to be
eventually delivered in the order they are sent unless mosh connection
breaks (agent forwarding uses this)
3) stream: like reliable datagram, but the packetization is not
necessarily spared and the packets may get merged or split on the way.
however the stream itself is quaranteed to be delivered.

- Should someone want to use oob to something more elaborate or data
intensive, the code would surely need some love. Currently reliable
traffic is sent so that packet containing reliable oob data (i.e. not
simply datagram type) gets resent with every single transport packet
until it's acked by the other end and any oob data that does have a
sequence number other than the next expected one, is dropped
immediately. This surely could be made much better, but on the other
hand, in agent forwarding it doesn't matter one way or another. However,
ack system as such is implemented so that changing the logic doesn't
hurt. It is perfectly legal to send multiple packets without waiting for
ack and it is also legal to skip acking the packet if also subsequent
packet has arrived and ack that instead. Anyways, as I said, in agent
forwarding it doesn't matter, but in future someone might like to look
into it. Could be nice student project, BTW.

- Adding new oob communicators is very simple. Example can be found in
agent code, but basically oob communicator name (string) is registered
to oob object and in return oob object exports a communicator object
that can be used in sending and receiving data. The registration is to
be done in both, server and client end. Any oob data received, which is
directed to an unregistered communicator name, is silently ignored.

- There is no way to signal end-of-stream in oob data. Not even in the
stream mode. Should oob ever be used so that some streams are passed
over oob so that a new communicator object gets dynamically allocated
during the connection and closed after the stream ends, signaling eof
would be a good idea. I didn't need it for agent forwarding (didn't
really need the stream format oob data either) so I didn't implement it.

- I know that oob code is something that may tempt people to add all
kinds of generic tunneling etc. Experimenting is fine, but making it
actually work will no doubt prove to be quite difficult. Flow control is
one of the issues that have caused a lots of gray hair in ssh side and
there are quite a few other issues too.

- The agent forwarding is enabled with option -A to mosh. The option
gets also passed to mosh-server and mosh-client processes.  If it's not
passed, the agent forwarding won't happen.

- The agent forwarding code is compiled in as default but can be
disabled with --disable-agent-forwarding option to configure. In my
personal opinion, there should be no reason to disable the code compile
time.  At least after it's been tested by the crowd.

- There is no --disable-out-of-band-extension configuration option and I
see no reason why there should be one.  If someone wants to add such a
thing, I don't mind.

- Oob data can be anything and it's delivered as simply a protobufs type
"bytes" which becomes std::string in c++.  However, in agent forwarding,
I used reliable oob datagrams so that they actually contain another
protobufs encoded packet (in agent.proto) that carries the agent
protocol packet and agent connection identifier. Even though data sent
over oob mechanism can be encoded in any way, my suggestion is to use
protobufs if it's packet data.

- The code is in my own github repo https://github.com/rinne/mosh-af/ in
branch agent-forwarding. Quick way to test.

$ git clone https://github.com/rinne/mosh-af.git

$ cd mosh-af

$ git checkout agent-forwarding

$ ./autogen.sh && ./configure && make

$ ssh-add -l  # you should see something here if you have agent running

$ "$(pwd)"/scripts/mosh --client="$(pwd)"/src/frontend/mosh-client
--server="$(pwd)"/src/frontend/mosh-server -A localhost

$ ssh-add -l  # you should see same stuff here if forward is ok

- I contrubute this code to Mosh project under the same license that
Mosh itself is distributed. All licensing options and clauses included.

- I agree that I didn't really follow the coding style of the rest of
Mosh very well.  Keith or someone can go through the code and modify the
style if they feel it's necessary.

Regards,
//Rinne



More information about the mosh-devel mailing list