Open
Conversation
- connection.rs: struct Connection and associated methods - main.rs: Prototype for primitive core1.0 negotiation
Not only message streams, but also the I/O stream has to go through this struct, because in mutliplexed mode it combines the both streams.
Contributor
Author
|
I will probably delete this branch in favor of #3 and go make messaging asynchonous from there. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We don't not need tokio just yet, because we don't subscribe to properties for now.
As soon as properties come into play, synchronous messaging will be okay for prototyping.
That is, it will suffice at first to only check for incoming messages when expecting an answer for a sent message and then, if the incoming message is
core.pubto handle that before handling the originally expected message.