You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How should this interact with asyncio's transport / protocol scheme? Currently the client example creates a "connected" UDP socket which means we never pass the "addr" argument to sendto(). Likewise in the server example we store the peer's initial address
What does this mean if QUIC is layered on top of ICE? Who makes the decisions as to which network path to use: ICE or QUIC?
What is the behaviour while the new network path is being validated? Do we continue using the previous network path until path validation completes?
The text was updated successfully, but these errors were encountered:
Currently
aioquic
has no explicit support for rebinding, i.e. dealing with changes in the peer's (IP address, port) tuple.The specs mention that we should perform path validation if we detect a network path change:
https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-9
Open questions:
How should this interact with asyncio's transport / protocol scheme? Currently the client example creates a "connected" UDP socket which means we never pass the "addr" argument to
sendto()
. Likewise in the server example we store the peer's initial addressWhat does this mean if QUIC is layered on top of ICE? Who makes the decisions as to which network path to use: ICE or QUIC?
What is the behaviour while the new network path is being validated? Do we continue using the previous network path until path validation completes?
The text was updated successfully, but these errors were encountered: