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
I almost did it this way but ran into the problem of sharing the routing table and over corrected, creating a single process bottleneck. When we spawn the connections they should remain the controlling process of their respective ports, we can eliminate the double handling/delegation of incoming network messages.
Router scope should reduce to managing the routing table for these processes. Does routing info need to be updated every message or just with heartbeats? Connection processes delegate to router functions to forward directly to outgoing connections. Should local subscriptions get registered as extra connections?
Move the main API and entry point to a new MAVLink module.
The text was updated successfully, but these errors were encountered:
I almost did it this way but ran into the problem of sharing the routing table and over corrected, creating a single process bottleneck. When we spawn the connections they should remain the controlling process of their respective ports, we can eliminate the double handling/delegation of incoming network messages.
Router scope should reduce to managing the routing table for these processes. Does routing info need to be updated every message or just with heartbeats? Connection processes delegate to router functions to forward directly to outgoing connections. Should local subscriptions get registered as extra connections?
Move the main API and entry point to a new MAVLink module.
The text was updated successfully, but these errors were encountered: