Lines Matching full:semantics
30 - We want to support both blocking and non-blocking semantics
46 passed to the QUIC implementation be configured to support datagram semantics
47 instead of bytestream semantics as has been the case with traditional TLS
50 datagram semantics. These changes are not minor, but there is no way around this
73 To function correctly and provide blocking semantics at the application level,
115 can implement the required semantics above.
147 able to support blocking semantics at the application level. Applications
148 which require blocking semantics would only be able to function in thread
199 need to change to using network BIOs with datagram semantics. For applications
220 Note that this is orthogonal to whether we provide blocking I/O semantics to the
222 either blocking or non-blocking semantics to the application, based on what the
252 supported blocking semantics, a sophisticated application could if it
258 (It is worth noting also that the implementation of blocking semantics at
261 build blocking semantics out of a non-blocking QUIC instance; this is not
272 substantially reworked to switch from bytestream semantics to datagram
273 semantics. Such applications will already need substantial changes, and
342 memory buffer with datagram semantics, is to be supported as part of MVP. This
445 their choice in. An application is free to define the semantics.