Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 16:54:20 -0700] rev 37544
wireproto: client reactor support for receiving frames
We can now feed received frames into the client reactor and it will
validate their sanity, dispatch them appropriately.
The hacky HTTP peer has been updated to use the new code. No
existing tests changed, somewhat proving the code works as
expected.
Rudimentary unit tests for the new functionality have been
implemented.
Differential Revision: https://phab.mercurial-scm.org/D3224
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 15:32:01 -0700] rev 37543
wireproto: introduce a reactor for client-side state
We have a nice state machine of sorts for reacting to server-side
events. Now it is time to implement the client equivalent.
We introduce a "clientreactor." It allows callers to request
that commands be issued. It has multiple modes of operation to
reflect what the underlying transport supports. e.g. for SSH,
we can perform wire sends immediately but for HTTP we need to
buffer sends until all command requests are received. In addition,
SSH allows sending multiple requests as long as the connection is
open. But HTTP/1.1 only allows sending request data once.
For SSH, we'll have one reactor per connection. For HTTP, we'll
have one reactor per HTTP request. But because code that calls
wire protocol commands should not be aware of how the underlying
transport works, this will all be abstracted away by the peer
interface.
Our crude HTTP peer has been updated to use the reactor instead
of formulating frames directly. No behavior should have changed
here and tests seem to confirm that.
Basic unit tests for the reactor behavior have been added.
Differential Revision: https://phab.mercurial-scm.org/D3223