Closed nobody93 closed 4 years ago
I don't know what you mean with "support Full-cone NAT". Do you mean if quant will work through a NAT? All QUIC implementations do.
Quant has its own socket-like interface. See the example client and server in bin/
.
Quant has its own socket-like interface. See the example client and server in
bin/
.
Hmm, that server uses http_parser, http_parser_execute, sorry if I missed something here?
I don't know what you mean with "support Full-cone NAT". Do you mean if quant will work through a NAT? All QUIC implementations do.
The full-core NAT is the client in a device behind the NAT initiates a connection to Cloud server, once the connection is established, the server can send messages to the client behind NAT anytime. I'll test it if the client and server in bin are using socket communication
Thank you.
Jupiter
Yes, the server implements the HTTP/0.9-over-QUIC test stuff that we use for interop testing. But it uses the quant API, which is not an HTTP API.
quant (and QUIC in general) place no special emphasis to keep NAT bindings alive. If you want keepalives, you need to send PING frames. quant at the moment doesn't allow an app to do this via the API, but that would be a trivial addition.
How difficult for the NAT bindings alive for one minute after the client in the device sending a QUIC message to the server? If that works, the server will be send any message back to the client in device within 1 minute window.
It depends on the NAT config. For UDP, I think you need to send a keep alive at least every 30 sec.
Hi Lars,
Could you clarify a couple of questions:
Does quant support Full-cone NAT? Could you point out which files support Full-cone NAT? Which test code has already build that capacity for testing?
Does quant support raw socket? Is there a test code for using raw socket, not http?
Thank you.
Kind regards,
Jupiter