Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deduplicate state machine in NTCP engine #2

Open
str4d opened this issue Oct 19, 2017 · 0 comments
Open

Deduplicate state machine in NTCP engine #2

str4d opened this issue Oct 19, 2017 · 0 comments

Comments

@str4d
Copy link
Owner

str4d commented Oct 19, 2017

NTCP handshake messages don't have IDs, and are identified based on send order. As a result, there are currently two state machines inside the NTCP engine:

  • IBHandshakeState and OBHandshakeState in HandshakeTransport.state, which handle the higher-level state transformations.
  • HandshakeState in InboundHandshakeCodec and OutboundHandshakeCodec, which defines which handshake message the codec is listening for or expects to be sent.

The reason for having two separate state machines is that HandshakeTransport calls stream.framed() to get a Framed transport that wraps the stream with a codec, and then itself wraps that transport. This makes it tricky to have a single state machine that is used by both parts of the engine (bearing in mind that I wrote the engine partly as an exercise in learning Rust). But having two state machines that are supposed to always be in sync is clearly prone to bugs.

We should deduplicate the state machine. I can see two ways of doing this:

  • Give a remote reference to the HandshakeTransport state machine to *HandshakeCodec (which is probably easier than I think it is using something like RefCell, which I still need to learn about).
  • Remove the use of Framed by implementing stream framing in HandshakeTransport, and pass the state machine through to the codec.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant