Bulk Leasequery design
The first step in bulk leasequery implementation is a design. We need written design that should cover:
- how the TCP connection is handled (connection management, whether one or multiple are possible in parallel, how to handle timeouts, connection closures etc)
- how the TCP framing is done. So far our life was easy - 1 query = 1 response = 1 UDP packet). That's not true anymore for TCP
- there are 5 different query types in BLQ. Some of them come from basic LQ which we already support. Need to investigate what kind of information is necessary to answer those queries
- some queries will require storing new information (Tomek recalls relay-id option). Need to figure out how to store this (the
store-extended-infomechanism and user context is most likely the way to go).
Also, it would be good to look at the leasequery mechanism in a broader context. There are three types: basic leasequery (that we already support), bulk leasequery (that we aim to implement right now) and also active leasequery (that we don't have immediate plans for now, but eventually it will be implemented for sure). The design should make some provisions that future ALQ implementation would be viable. Background info: the ALQ is a cool concept. The requestors can subscribe to active lease changes. One of the usage models is: get bulk of the data via BLQ and then keep it updated with ALQ. Overall, this almost looks like lease updates and backup server we have in HA. Anyway, ALQ is out of scope for now.