mirror of
https://gitea.invidious.io/iv-org/litespeed-quic.git
synced 2024-08-15 00:53:43 +00:00
04f8f447b2
- [FEATURE] IETF Client 0-RTT support. - [BUGFIX] Do not schedule MTU probe on first tick. - [BUGFIX] Parsing DATAGRAM frame. - [BUGFIX] If push promise fails, do not invoke hset destructor. - [BUGFIX] Client: When connections are IDed by port number, check DCID. Fixes issue #176. - Revert the 2.22.1 lsquic_is_valid_hs_packet change. All that was necessary is a change to the way we call it in lsquic_engine. No change to the function itself is required.
28 lines
1.2 KiB
ReStructuredText
28 lines
1.2 KiB
ReStructuredText
**************************
|
|
Frequently Asked Questions
|
|
**************************
|
|
|
|
API/Design
|
|
==========
|
|
|
|
*Why have a separate engine for server and client? Surely traffic
|
|
could be differentiated as much as it needs to be internally in one
|
|
engine?*
|
|
|
|
The traffic *cannot* be differentiated for gQUIC versions Q046 and Q050.
|
|
This is because in these versions, the server never includes a connection
|
|
ID into the packets it sends to the client. To have more than one
|
|
connection, then, the client must open a socket per connection: otherwise,
|
|
the engine would not be able to dispatch incoming packets to correct
|
|
connections.
|
|
|
|
To aid development, there is a :macro:`LSQUIC_FORCED_TCID0_VERSIONS` that
|
|
specifies the list of versions with 0-sized connections. (If you, for
|
|
example, want to turn them off.)
|
|
|
|
Once gQUIC becomes deprecated in the future, there will remain no technical
|
|
reason why a single engine instance could not be used both for client and
|
|
server connections. It will be just work. For example, the single
|
|
engine settings :type:`lsquic_engine_settings` will have to be separated
|
|
into client and server settings, as the two usually do need to have
|
|
separate settings.
|