Hacker News new | past | comments | ask | show | jobs | submit login

Re: 1.- You'll probably still need it if the NATed party is recvonly, i.e. it expects to just recrive data without it explicitly sending any first.



I would presume that the receiver will still make an output request to the QUIC endpoint to at least bring-up the connection/stream, which should be enough to populate the path in NAT tables, no? It shouldn't be any more wasteful than the regular process which receives packets out-of-band but still needs a signaling channel. This just does in-band signaling, so you bring up the connection, perform signaling, then open a new QUIC stream to receive data.


You're right. I thought your comment was replying that in current implementations (not in the context of QUIC), the NATed peer wouldn't need STUN anyways, as of today. I had lost the context of it referring to an hypothetical implementarion over QUIC.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: