Lines Matching refs:to
5 internal to the libssl QUIC implementation, discusses the underlying design
7 It also identifies potential hazards to existing applications, and identifies
16 - The application must have the ability to be in control of the event loop
17 without requiring callbacks to process the various events. An application must
18 also have the ability to operate in “blocking” mode.
21 APIs; using custom network interaction BIOs in order to get the best
23 handling, using fibres). Would prefer to use the existing APIs - they don’t
24 want to throw away what they’ve got. Where QUIC necessitates a change they
25 would be willing to make minor changes.
30 - We want to support both blocking and non-blocking semantics
34 for an application to do its own polling and make its own event
37 - We want to support custom BIOs on the network side and to the extent
46 passed to the QUIC implementation be configured to support datagram semantics
49 to make substantial changes to the implementation of those custom BIOs to model
55 writable. In many cases we need to handle these events simultaneously (e.g. wait
61 underlying BIO provided to the QUIC implementation to provide it access to the
62 network. This is independent of and orthogonal to the application interface to
69 used for the calls to the underlying network BIOs. To illustrate this point, we
74 our QUIC implementation must be able to block such that it can respond to any of
90 calls to send(3) or recv(3) may block for some arbitrary period of time, meaning
103 of the size we wish to send is writeable, so a send(3) call could block
107 due to the possibility of other threads racing between the call to select(3)
108 and the subsequent I/O call. This undermines our intentions to support
112 directly but uses the BIO abstraction to access the network, so these issues are
120 any given BIO implementation has such a BIO call correspond to only a single
122 trying to implement QUIC on top of blocking I/O in this way would require
131 - a thread which exists solely to execute blocking calls to the `BIO_write` of
133 - a thread which exists solely to execute blocking calls to the `BIO_read` of an
135 - a thread which exists solely to wait for and dispatch timeout events.
137 This could potentially be reduced to two threads if it is assumed that
146 - There is a hard requirement for threading functionality in order to be
147 able to support blocking semantics at the application level. Applications
148 which require blocking semantics would only be able to function in thread
154 over OpenSSL's use of resources, such as allowing the application to do its
159 to be `2n` extra threads spawned.
163 to be transmitted as soon as they are generated. QUIC packets contain fields
164 such as the ACK Delay value, which is intended to describe the time between a
166 of this field is necessary to correct calculation of connection RTT. It is
167 therefore important to only generate packets when they are ready to be sent,
169 aligns optimally to non-blocking I/O and which cannot be accommodated
173 `BIO_write` calls, they will need to be adapted to support this, which is
174 likely to require substantial rework of those custom BIOs (trivial locking of
175 calls obviously does not work since both of these calls must be able to block
178 Moreover, this does not appear to be a realistically implementable approach:
180 - The question is posed of how to handle connection teardown, which does not
181 seem to be solvable. If parallel threads are blocked in blocking `BIO_read`
182 and `BIO_write` calls on some underlying network BIO, there needs to be some
183 way to force these calls to return once `SSL_free` is called and we need to
185 any way to do this. *At best* we might assume the BIO is a `BIO_s_dgram`
190 This is the only portable way to ensure that a recv(3) call to the same socket
192 to be far more disruptive than configuring the socket into non-blocking mode).
196 appear to be any viable solution to the teardown issue.
199 need to change to using network BIOs with datagram semantics. For applications
200 using custom BIOs, this is likely to require substantial rework of those BIOs.
204 applications would still have to completely rework their implementation of those
205 BIOs. In any case, it is expected to be comparatively rare that sophisticated
212 our internal approach to I/O to be flexibly adapted in the future as
217 I/O, as (as mentioned above) it would lead to suboptimal performance due to the
220 Note that this is orthogonal to whether we provide blocking I/O semantics to the
221 application. We can use blocking I/O internally while using this to provide
222 either blocking or non-blocking semantics to the application, based on what the
227 single I/O operation to be made non-blocking, not all OSes support this (e.g.
228 Windows), thus this cannot be relied on. As such, we need to configure any
232 fewest disadvantages and is the only approach which appears to actually be
242 non-`no-sock` builds, so this does not appear to raise any portability
246 allows an application to provide its own implementation of a
247 select(3)-like function. In fact, this has the potential to be quite
248 powerful and would allow the application to implement its own pollable
253 wished choose to implement a custom blocking memory BIO and implement a
259 the application level also does not rely on any privileged access to the
263 there should be no need for an application to do so.)
269 - Applications will already have to make changes to any network-side BIOs,
270 for example switching from a `BIO_s_socket` to a `BIO_s_dgram`, or from a
271 BIO pair to a `BIO_s_dgram_pair`. Custom BIOs will need to be
272 substantially reworked to switch from bytestream semantics to datagram
279 - In order for an application to be confused by us putting a socket into
280 non-blocking mode, it would need to be trying to use the socket in some
281 way. But it is not possible for an application to pass a socket to our
282 QUIC implementation, and also try to use the socket directly, and have
284 also be trying to make use of the same socket.
286 - There are some circumstances where an application might want to multiplex
292 correctly. (We may offer some functionality in future to allow this to be
297 - The poll descriptor interface adds complexity to the BIO interface.
304 interface, the application would actually be able to exercise more control
307 - Feasible to implement and already working in tests.
308 Minimises further development needed to ship.
313 - Does not require an application-provided network-side custom BIO to be
314 reworked to support concurrent calls to it.
316 - The poll descriptor interface will allow applications to implement custom
334 or be configurable by QUIC to this end.
340 We need to support not just socket FDs but arbitrary BIOs as the basis for the
342 memory buffer with datagram semantics, is to be supported as part of MVP. This
343 must be reconciled with the desire to support application-managed event loops.
345 Broadly, the intention so far has been to enable the use of QUIC with an
347 appropriate OS-level synchronisation primitive to the application. On \*NIX
354 (potentially) advanced meaningfully, and the application is expected to reenter
365 such as `BIO_dgram_pair` which do not naturally correspond to any OS primitive
371 In order to accommodate these various cases, we draw a distinction between
375 synchronisation primitive, which can be used to determine when
376 the BIO might be able to do useful work once more.
379 primitive, but its state only changes in response to calls made to it (or to
399 As such, an API to expose a synchronisation primitive should be of a tagged
402 A BIO object will provide methods to retrieve a pollable OS-level
403 synchronisation primitive which can be used to determine when the QUIC state
405 abstraction layer. Equivalent SSL object API calls which forward to the
436 Winsock socket handle on Windows. These use the same type to minimise code
444 `BIO_POLL_DESCRIPTOR` structure is provided for applications to store values of
445 their choice in. An application is free to define the semantics.
447 libssl will not know how to poll custom poll descriptors itself, thus these are
452 For `BIO_s_ssl`, the `BIO_get_[rw]poll_descriptor` functions are equivalent to
454 functions are equivalent to calling `BIO_get_[rw]poll_descriptor` on the
455 underlying BIOs provided to the SSL object. For a socket BIO, this will likely
469 There are various circumstances which need to be handled:
471 - The QUIC implementation wants to write data to the network but
472 is currently unable to (e.g. `BIO_s_dgram_pair` is full).
475 The only limit comes when QUIC flow control (which only applies to
476 application stream data) applies a limit; then calls to e.g. `SSL_write` we
479 - The QUIC implementation wants to read data from the network
480 but is currently unable to (e.g. `BIO_s_dgram_pair` is empty).
482 Here calls like `SSL_read` need to fail with `SSL_ERROR_WANT_READ`; we
487 implement a custom BIO, custom poll descriptor and custom poller to facilitate
499 blocking mode, so it is not possible to use the initial state of an underlying
500 socket to determine if the application wants to use non-blocking I/O or not.
503 As such, an explicit call is introduced to configure an SSL (QUIC) object into
511 Applications desiring non-blocking operation will need to call this API to
513 default for parity with traditional Berkeley sockets APIs and to make things
514 simpler for blocking applications, which are likely to be seeking a simpler
516 and thus blocking mode defaults to off when used with such a BIO.
518 A method is also needed for the QUIC implementation to inform an underlying BIO
522 equivalent to a call to `SSL_set_blocking_mode()`.
528 function (e.g. `select()`) or, if configured, custom poller function, to block.
529 This will be implemented by an internal function which can accept up to two poll
536 to off.
