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
The UDP RFC lacks support for logical connections, which means that there are SP protocols that cannot be used with it (any that require a backtrace, like REQ/REP), and that it cannot be used in device constructs.
We need the ability to create and manage logical connections. Furthermore, we need protocol support for keeping these active, to ensure that we tickle firewalls etc. that may use UDP state tracking to keep ports open or NAT mappings active. And like those, we need a way to detect an idle session and clean it up.
The answer is, unfortunately, that we have to build a stateful connection layer on top of UDP. Fortunately it doesn't need to provide most of the overhead of TCP -- we don't need reliable delivery, we don't need guarantees against reordering or message alteration, or duplication.
Much of the protocol can be done in a stateless/idempotent manner, using just four lower level message types:
DATA
REQUEST_CONNECTION
ACKNOWLEDGE_CONNECTION
ERROR
I've updated the RFC to deal with the particulars.
The text was updated successfully, but these errors were encountered:
The UDP RFC lacks support for logical connections, which means that there are SP protocols that cannot be used with it (any that require a backtrace, like REQ/REP), and that it cannot be used in device constructs.
We need the ability to create and manage logical connections. Furthermore, we need protocol support for keeping these active, to ensure that we tickle firewalls etc. that may use UDP state tracking to keep ports open or NAT mappings active. And like those, we need a way to detect an idle session and clean it up.
The answer is, unfortunately, that we have to build a stateful connection layer on top of UDP. Fortunately it doesn't need to provide most of the overhead of TCP -- we don't need reliable delivery, we don't need guarantees against reordering or message alteration, or duplication.
Much of the protocol can be done in a stateless/idempotent manner, using just four lower level message types:
I've updated the RFC to deal with the particulars.
The text was updated successfully, but these errors were encountered: