chrysn / aiocoap

The Python CoAP library
Other
264 stars 119 forks source link

Inform application of transport related events #316

Open chrysn opened 1 year ago

chrysn commented 1 year ago

There are some events that some transports can expose, most notably "the connection dropped", and which applications could be interested in.

Exposing them needs answers to three questions:

  1. How is this best done mechanically? Events on the .remote that the application can subscribe to, or events on the context? Is there a good Python idiom (async iterators?) that play well in both directions of cancellation?
  2. Which events are best exposed, and at what semantic level?

    Currently I'm leaning toward only exposing "Connection unavailable", which in connected protocols would be indicated at shutdown, abortion or keepalive timeout, and on unconnected protocols on retransmission timeout exceeded.

    Other possible events are "connection established", "ping received" or "CSM set", but see question 3.

  3. Which events does it make sense to expose from a CoAP architecture PoV? Is there a danger of leading users towards patterns that only work on one transport?

    (That's why I'm leaning toward only doing connection-lost: Something along those lines is present almost everywhere, and it can be described to be implemented in a best-effort way -- no guarantees it will fire when the peer goes down, only at some point after attempted communication.)