On 03/08/2018 05:14 PM, ElChino wrote:
Would it not make more sense to support this in some kernel-driver?
Did you watch the video?
He explains the motivation reasonably well for a short video: The
priorities being considered are very application-specific.
Certainly it's possible that a generalized QUIC implementation for the
OS could be produced which has options for a variety of arbitrary kinds
of these applications (basic web page service -vs- email access -vs-
file transfer -vs- audio/video 1-way -vs- audio/video N-way interactive
-vs- ...), and then the applications written to use QUIC could specify
which of these generic profiles are desired. Offhand, and without
thinking it through too far, I envision this as a socket option kind of concept, which unfortunately is where all the random crud like
TCP_NODELAY gets dumped for protocols; similar socket options named
QUIC_EMAIL and QUIC_XFER and so forth would at least fit there in a
somewhat orthogonal sense.
Insofar as they're apparently in the midst of experimenting, I can't say
I'm surprised that they're staying high up in application space so far.
It would be nice if, after having experimented for some time inside
Chrome and friends, Google could provide such a kernel implementation
plus some proof-of-concept reference applications that are written just
to show off what the protocol can do.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)