Hi,

We've been looking at the monitor_instance pdg example provided with Houdini ($HFS/houdini/pdgd/examples/monitor_instance/), and are unclear about the websocket client creation behavior.

In register_pdg_instance.py, the client variable in register() function is None if there is no server started on the local machine by calling startPDGStateServer(). If we want to monitor an instance on the farm, the server and client will not be on the same machine. What is the way for us to start a client without starting the server in the same machine?

Also, is there documentation for the _pdgd.so library if we want to understand the behavior better?

Thanks,

Wayne

Hi!

I'll try to explain a bit about pdgd and the example, but I'll address your question right after the explanation (feel free to jump to it!).

It's important to note that pdgd is still in a very experimental state, we are working to provide better API, documentation and examples with the next Houdini release (and as long as there are no internal breaking changes, the functionality will also be added to Houdini 18). You can find some documentation here: https://www.sidefx.com/docs/houdini/tops/pdgd/index.html [www.sidefx.com]

You can think of pdgd as a generalized subscription based event system, you probably have seen the other examples, and under examples/visualizer there are a few examples showing the most basic usage of pdgd.

Pdgd is extensible, so you can use it to expose your own data, this is done by writing subscription handlers, we're working on some utility classes to make it really straightforward to write them.

This monitoring example is meant to show two features, the first is how pdgd can be extended, the custom_subscription_handler.py creates a subscription handler that will be registered to pdgd, the second feature shown is how to use the remote graph node to connect to a remote pdgd server.

The custom subscription handler holds a list of machine addresses, it provides two commands: “register” and “deregister”. The houdini instance that will be monitoring other instances starts a pdgd server so other instances can communicate with it.
Even though this pdgd server will expose pdg graphs, that's not what we're interested in this case, the important thing is the custom subscription handler we created. Remote instances can connect to the monitoring instance and use the register command to let it know they started to cook a pdg graph, they can also deregister themselves to signal their data won't be available anymore.
The “list_external_pdg_addresses” node in the monitor.hip file creates a pdgd visualizer and subscribes to the custom subscription handler (registered as “external_pdg”), it will receive a snapshot with all the data held by that subscription handler, in this case it is just a list of addresses. The next node (“create_remote_viewers”) will create a remote graph node for each registered address.

On the other side of all this, we have the instances doing pdg work, the monitoring instance wants to remotely watch their work. We have no mechanisms for knowing that a houdini instance in the network started, that's why we need the register/deregister system described above, so each instance must report itself to the monitor. This probably can be done by other means and each network will have its solutions and limitations on how to achieve this.
A remote instance must ensure that its pdg data is available, this is done by starting a pdgd server, once this server is running, other houdini instances can attach to it and visualize their TOP graphs using a remote graph node.
Before cooking its graph, every remote instance will need to first register to the monitor instance, in this example, this is done by connecting to the monitor instance's pdgd and sending a “register” command, the code for this is in the “register” method in register_pdg_instance.py, this script is executed in the first node of the pdg graph.

Summing up:
* Monitor instance
1. Creates a custom subscription handler, allowing external instances to register/deregister themselves
2. Starts a pdgd server, in order to make that subscription handler available to the network
3. Listens for registrations, for each registration it creates a remote graph pointing to it

* Remote instance
1. Starts a pdgd server, in order to expose its pdg data
2. Sends a register command to the monitor instance
3. Proceeds to cook its graph

About your question, the example sets the monitor address to ‘localhost:1314’, you just need to set it to the address of your monitoring machine. Please note that in a farm setup you may have network restrictions such as firewalls, so you need to make sure that the monitor instance and the remote instances can communicate to each other. The register/deregister strategy the example uses will not work in situation where the monitor instance can ping the remote instance but not the other way around, in this case you would need a different approach.

I hope this helped, please let me know if you have any further questions,
- Joab