]> asedeno.scripts.mit.edu Git - PuTTY.git/commit
Rewrite agent forwarding to serialise requests.
authorSimon Tatham <anakin@pobox.com>
Sun, 29 Jan 2017 19:40:38 +0000 (19:40 +0000)
committerSimon Tatham <anakin@pobox.com>
Sun, 29 Jan 2017 20:25:09 +0000 (20:25 +0000)
commit4ff22863d895cb7ebfced4cf923a012a614adaa8
tree358b4a7fb4b841344289ae3792aec6793b6901f9
parenteb2fe29fc975b19a3b3692fced03559e705881d9
Rewrite agent forwarding to serialise requests.

The previous agent-forwarding system worked by passing each complete
query received from the input to agent_query() as soon as it was
ready. So if the remote client were to pipeline multiple requests,
then Unix PuTTY (in which agent_query() works asynchronously) would
parallelise them into many _simultaneous_ connections to the real
agent - and would not track which query went out first, so that if the
real agent happened to send its replies (to what _it_ thought were
independent clients) in the wrong order, then PuTTY would serialise
the replies on to the forwarding channel in whatever order it got
them, which wouldn't be the order the remote client was expecting.

To solve this, I've done a considerable rewrite, which keeps the
request stream in a bufchain, and only removes data from the bufchain
when it has a complete request. Then, if agent_query decides to be
asynchronous, the forwarding system waits for _that_ agent response
before even trying to extract the next request's worth of data from
the bufchain.

As an added bonus (in principle), this gives agent-forwarding channels
some actual flow control for the first time ever! If a client spams us
with an endless stream of rapid requests, and never reads its
responses, then the output side of the channel will run out of window,
which causes us to stop processing requests until we have space to
send responses again, which in turn causes us to stop granting extra
window on the input side, which serves the client right.
ssh.c
windows/winpgntc.c