I think we should perhaps back up a bit--
Under normal circumstances, robots will not generally directly talk to each other. QoS/alarms/etc won't "pass through" different robots. Queues control the flow of messages from hub to hub; there is not any reason why a robot would normally 'need to' talk directly to another robot. Also, it would be relatively difficult to arbitrarily execute "any code" on the UIM environment unless you were already authenticated to the environment (e.g. you know the UIM administrator password). If there are firewalls in between, then robots would not be able to directly talk to each other point-to-point.
But, for an example of how the UIM routing works, try the following in your UIM environment:
1. Pick any two hubs which are separated by one or more tunnels.
2. choose any controller probe on a robot under hub #1 and highlight it in IM
3. press CTRL+P for the probe utility and run the "nametoip" callback.
4. provide the full UIM address of any controller probe under the second hub (e.g. /Domain/hub2/robotname/controller) and click the green 'arrow' button.
5. An IP:port will be returned, which is most likely the IP address of the hub you're on, or the nearest tunnel hub, and a port in the 48*** range.
Anything connecting to the given IP:port in this result will be "proxied across" the tunnel(s) and ultimately delivered to the UIM address you've given.
So in this way, any robot could interact with any other robot -- but only in the context of UIM, e.g. executing callbacks and so forth. (You could, for example, put a LUA script on a NAS on Hub A that runs a get_info callback vs. a robot under Hub C and this would work fine as long as you provided the appropriate full UIM address of the robot.)