... | ... | @@ -42,7 +42,7 @@ The following diagram illustrates the new class hierarchy: |
|
|
|
|
|
When a query packet arrives its queries will be pushed onto a queue. The queue is monitored a pool by one or more query worker threads. Each worker thread is responsible for submitting a single query against the lease store, iteratively fetching the results, and pushing results as XID/binding pairs to connection's outbound queue. The connection thread will add the binding pairs to the current TCP packet until it is full and then send it asynchronously. Subsequent pairs are adding to a new packet. This continues until there are no more queued queries.
|
|
|
|
|
|
A conceptualization of the processing in pseudo code follows:
|
|
|
A conceptualization of the processing for V6 in pseudo code follows:
|
|
|
|
|
|
```
|
|
|
// Run() logic in a ConnectionThread
|
... | ... | @@ -123,6 +123,8 @@ TcpConnection::pushToSend(xid, response) { |
|
|
}
|
|
|
```
|
|
|
|
|
|
V4 processing would be very similar but not identical as the messages and contents vary from somewhat from their V6 counter-parts.
|
|
|
|
|
|
We may need a gating mechanism (e.g. condition variable in pushToSend()), based on a maximum number of bindings queued for send (per connection) so query workers do not create enormous outbound queues. In other words, we need to avoid outrunning the connection's ability to send by too avoid memory exhausting et al. In practice this may be a non-issue but it is better to allow for it now.
|
|
|
|
|
|
## Query Execution
|
... | ... | |