Module tox::toxcore::timeout [−] [src]

Managing requests IDs and timeouts.

Peers are to be timed out when they do not show any activity before running into a timeout.

Timeout data to store:

Instant (when was the last interaction with given peer)
request ID (from PingReq, GetNodes, ..other?)
PK (unique identifier of a peer)
- does it really need to be stored? can't it be a reference to PK stored somewhere else? it's "just" 32 bytes, but still
- can it be replaced by futures?

By what storage needs to be accessed:

timeout, based on Instant::elapsed() < Duration::from_secs(TIMEOUT);
- sorting according to increasing timeout?
- multiple storages according to what the timeout is for?
Request ID: remove NodeTimeout from the queue if IDs match and spawn TimeoutFuture

store NodeTimeout in VecDeque
- separate queues for each PacketKind request
append new timeouts at the end of the queue
front() to check if first timeout is to be triggered
- pop_front() to remove timeout from queue if it's past it

Once it's past the NodeTimeout, remove it from both queue and:
- initial implementation: from Kbucket
- better implementation: modify NodeState in table of NodeInfos, and act accordingly to the NodeState

Possibly create a new TimoutFuture for each known node – future is created to trigger GetNodes requests.

NodeTimeout	A DHT node's associated timeout info.
TimeoutQueue	Store & manage timeout data.

Enum stating whether we consider responsiveness of given DHT node as Good, Bad or Unresponsive.

BAD_TIME	Number of seconds after which DHT node is considered to be `Bad`. See `NodeState`.
PING_TIMEOUT	Number of seconds to reach ping timeout. DHT node has to respond to a `PingReq` in less than `PING_TIMEOUT` seconds.
RESPONSE_CHECK	Number of seconds between each time that a DHT node needs to be checked for responsiveness by sending to it a `GetNodes` request.
UNRESPONSIVE_TIME	Number of seconds after which DHT node is considered to be `Unresponsive`. See `NodeState`.