I'm working on a quic gateway which accepts quic connections from outside and translate them to http1.1 requests and forward them to the target server. Using tokio handles much of the complexity in this project (for each request I can spawn a tokio task which awaits the response from the original server and then returns it to the client). The problem is that I do not own the IP of the targets, and I capture udp packets using raw AF_PACKET socket. So I can't use the tokio's UdpSocket which is required by tokio-quiche.
Quiche itself is agnostic against source of packets. Is it possible to use a trait for receiving packets in tokio-quiche and implement it for tokio::net::UdpSocket? With that trait, custom users like me can avoid the complexity of using quiche directly and still use tokio-quiche, without making much difference for normal users.
I have an incomplete version of this which I'm currently using in my project. I can polish and upstream it if desired.
I'm working on a quic gateway which accepts quic connections from outside and translate them to http1.1 requests and forward them to the target server. Using tokio handles much of the complexity in this project (for each request I can spawn a tokio task which awaits the response from the original server and then returns it to the client). The problem is that I do not own the IP of the targets, and I capture udp packets using raw AF_PACKET socket. So I can't use the tokio's
UdpSocketwhich is required by tokio-quiche.Quiche itself is agnostic against source of packets. Is it possible to use a trait for receiving packets in tokio-quiche and implement it for
tokio::net::UdpSocket? With that trait, custom users like me can avoid the complexity of using quiche directly and still use tokio-quiche, without making much difference for normal users.I have an incomplete version of this which I'm currently using in my project. I can polish and upstream it if desired.