This PR refactors how the QUIC connections are handled between node clients and servers (same applies for control node).
Before each Connection would be stored in a DashMap, now each Connection is in its own task where we can easily
manage failures and reconnect. The message API now just forwards Requests to each task with unbounded_channel.
Further additional error handling between client and server is added in order to properly return error code in host functions.
There are still some open questions with the new architecture:
connecting or reconnecting to the node will forever wait if the node does not exist or is down
when node fails what happens to all pending requests
three modules for transport (quinn, s2n-quic and tcp) exist, @bkolobara mentioned maintaining all three is unnecessary
Next steps:
Implement message chunking to control congestion
I've also run benchmark against this branch, no significant changes in performance. In fact the results across multiple runs seem more consistant.
This PR refactors how the QUIC connections are handled between node clients and servers (same applies for control node).
Before each
Connectionwould be stored in aDashMap, now eachConnectionis in its own task where we can easily manage failures and reconnect. The message API now just forwardsRequeststo each task withunbounded_channel. Further additional error handling between client and server is added in order to properly return error code in host functions.There are still some open questions with the new architecture:
Next steps:
I've also run benchmark against this branch, no significant changes in performance. In fact the results across multiple runs seem more consistant.