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
This allows remote nodes reach each other using some configured name replacing a more complex route with this name.
We can develop this idea of replacing a route with an alias to other cases.
If we need a complex route and especially if this route may change, we might want to present this route to the user code as a static alias.
For example if a device needs to access a cloud node over multiple transport hops. In that case there would be a configuration variable with a route to the cloud node. But if the route to the cloud node is changing, for example some connection worker is changing then this variable needs to be updated.
A local alias worker might help here by storing the up-to-date routes to remote workers while being accessible via static local address. This way the user code only uses something like "cloud" in the routes and it's expanded to the full route in the alias worker.
Another application of this approach could be in the IoT scenario when there is an additional node between device and the internet. Device nodes will need to deal with shorter addresses and do less communication to conserve energy while additional nodes would maintain sessions, connections and complex routes.
This additional device then may translate a simple alias given by a device into a more complex route and back.
These alias workers act similarly to channels and may be implemented as such.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Ockam Services has a static forwarding service, which creates an alias for some remote route.
This allows remote nodes reach each other using some configured name replacing a more complex route with this name.
We can develop this idea of replacing a route with an alias to other cases.
If we need a complex route and especially if this route may change, we might want to present this route to the user code as a static alias.
For example if a device needs to access a cloud node over multiple transport hops. In that case there would be a configuration variable with a route to the cloud node. But if the route to the cloud node is changing, for example some connection worker is changing then this variable needs to be updated.
A local alias worker might help here by storing the up-to-date routes to remote workers while being accessible via static local address. This way the user code only uses something like "cloud" in the routes and it's expanded to the full route in the alias worker.
Another application of this approach could be in the IoT scenario when there is an additional node between device and the internet. Device nodes will need to deal with shorter addresses and do less communication to conserve energy while additional nodes would maintain sessions, connections and complex routes.
This additional device then may translate a simple alias given by a device into a more complex route and back.
These alias workers act similarly to channels and may be implemented as such.
Beta Was this translation helpful? Give feedback.
All reactions