Throughout the examples, the source cage just addresses the target cage by name, for example

result = pmnc.execute.on("target_cage").target_module.target_method(*args, **kwargs)

but does not mention neither a protocol, nor a node address, nor a port.

How does Pythomnic know where to send the call to ? The ultimate answer is that all the cages reachable from a cage are configured in config/config_execute_on.py. Technically you could explicitly configure the way any other cage is reachable from this one by editing that file, but normally there is no need to touch it at all.

The default behaviour is for all the cages on the network to be discovering their peers' location dynamically at runtime. If you examined the mentioned configuration file, this behaviour is configured in channels to imaginary cages "unknown" and "unknown_queue". If there is no explicit configuration for target_cage, unknown is used, and if there is no explicit configuration for target_cage_queue, unknown_queue is used. These channels both employ a UDPDiscover class behind the scene. This way, when

pmnc.execute.on("target_cage").target_module.target_method(*args, **kwargs)

is executed, a series of UDP packets is being broadcast to the network, so as to ask "where is target_cage" ?. All the cages on the network presumably listen to the same UDP port and therefore each cage receives the request. If a cage named target_cage receives the request, it responds with a matching broadcast "target_cage is accessible via channel such and such". The enquiring cage receives the response and binds the name "target_cage" to the discovered channel. Once the channel is obtained, the above call becomes

pmnc.execute.on(channel such and such).target_module.target_method(*args, **kwargs)

and is executed. The binding will last for a while, preventing broadcasts from being dispersed at each call. This way all the cages on the network are capable of communicating seamlessly without knowing one another's exact address.

There is another important point about this - you can have more than one instance of target_cage on the network. If there is, they will all respond to the received broadcast and the first response received by the discovering cage will take the binding. Also, the identically named cages can come and go independently, and the application will keep up as soon as any is able to respond to a broadcast.

This has an important implication - the name of the cage becomes the cage. Any cage with such name should be able to perform such processing. Therefore you have to pick a name for a cage carefully, it will become the name of the service the cage provides. For example, for a cage to become a health monitor it needs to be called exactly health_monitor.