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 network graph currently implementable with pyzmp has to be within one interpreter (ie. in one process tree).
We need to shift to a network graph implementable within a machine or a LAN.
This is a matter of :
choosing ipc:// or tcp:// transport ( check zmq-connect for Reference ), and relying on this for communication (we currently rely on process name...). Since we are using ZMQ, getting basic network communication to work for process, machine or LAN is quite simple.
making our node/service registry a specific node of the zmp network. Just like a "master" that is supposed to always be available on the network, to all nodes. If it goes down the whole zmp network goes down.
This is a frail but simple design, good for a first implementation. A following implementation can be to make that master Highly available.
the communication of which node goes up, and detection of which nodes went down, should be implemented with zmp as well. We need to avoid relying on extra communication means, to simplify the understanding of the whole system for newcomers. There may be some hidden challenges lurking around the corner that we need to conquer before we can achieve this...
The text was updated successfully, but these errors were encountered:
The network graph currently implementable with pyzmp has to be within one interpreter (ie. in one process tree).
We need to shift to a network graph implementable within a machine or a LAN.
This is a matter of :
ipc://
ortcp://
transport ( check zmq-connect for Reference ), and relying on this for communication (we currently rely on process name...). Since we are using ZMQ, getting basic network communication to work for process, machine or LAN is quite simple.The text was updated successfully, but these errors were encountered: