You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
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.)
The text was updated successfully, but these errors were encountered:
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:
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.)
The text was updated successfully, but these errors were encountered: