NTAP / quant

QUIC implementation for POSIX and IoT platforms
BSD 2-Clause "Simplified" License
289 stars 35 forks source link

Core features check (question) #66

Closed nobody93 closed 4 years ago

nobody93 commented 4 years ago

Hi Lars,

Could you clarify a couple of questions:

Thank you.

Kind regards,

Jupiter

larseggert commented 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/.

nobody93 commented 4 years ago

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

larseggert commented 4 years ago

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.

nobody93 commented 4 years ago

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.

larseggert commented 4 years ago

It depends on the NAT config. For UDP, I think you need to send a keep alive at least every 30 sec.