Add multipath #28
Add multipath #28
Conversation
divagant-martian
force-pushed
the
multipath-quinn-0.11.x
branch
from
6f37612 to
f5485c2
Compare
divagant-martian
force-pushed
the
multipath-quinn-0.11.x
branch
from
6fa6b81 to
f3f1a44
Compare
|
Hi there! |
|
@MikeRomaniuk This is still very early right now, maybe like the first 5% if that. We are still in the process of restructuring things for the basic building blocks for multipath to be there. If you want to help you can take a look at the code so far, but it is currently still rather difficult to point at anything. It will probably be easier to jump in once we have the most basic 2-path connection working. But if you're keen to really help, right now it is mostly a case of trying to understand what would be a useful next step based on the specs and code. And then try and implement some of it. With just two of us this seems to move us forwards so far. |
|
@MikeRomaniuk Can I inquire as to what your usecase is? |
This makes sure that the sequence numbers of the CIDs are sequential per path. Which is what it needs to be.
This makes sure that the sequence numbers of the CIDs are sequential per path. Which is what it needs to be.
It probably is never missing, but still nice to write like this
|
@flub, thanks for answering. |
|
@MikeRomaniuk The usecase does kind of matter, because we have a very specific usecase in mind (documented in my fosdem talk, though the recording is terrible - i should re-record that sometime). We want to do the absolute minimum we can do for our usecase, and this keeps the number of public APIs that will be needed small as well. The multipath spec does give you enough to make a largely interoperable protocol, but also still leaves a lot of things as essentially further research topics. The largest one is probably packet scheduling, also things like how to interoperate with the ack-frequency spec and probably a bunch more that escape me right now. So what you want to get out of this does matter in that regard. |
|
@flub, I might have understood your speech in the video wrong, so feel free to correct me. |
This is already set to the right value.
fun times
It fixes up the state of the paths kept on the connection and attempts to document them a bit. The MAX_PATH_ID and any possible PATH_NEW_CONNECTION_ID frames are unfortunately not sent in the same datagram, because the endpoint dirver issues CIDs asynchronously.
This is way to easy to get wrong, but I also checked with main.
Sends and receives PATH_CIDS_BLOCKED and PATHS_BLOCKED correctly
* ensure path status is only queued one, and only when changed * schedule sending the path status frame at a more appropriate instant * fix clippy, save a line * keep within the multipath world * register the sent frame with retransmits
- Allows accessing the Path struct if you have a PathId - Adds a Connection::path_events broadcast channel for the application to consume path events.
- Allows accessing the Path struct if you have a PathId - Adds a Connection::path_events broadcast channel for the application to consume path events.
Abandons a path, issues new MAX_PATH_ID and CIDs, closes connection if last path is abandoned. Removes accepted reset tokens when a path is abandoned.
No description provided.