This project has moved and is read-only. For the latest updates, please go here.

Running multiple data publishers

Aug 2, 2011 at 7:26 PM

I'd like to run 2 data publishers, one on IPv6 for the OpenPDC manager and one on IPv4 for applications to subscribe to data. The reasoning is that the OpenPDC manager expects to see a data publisher on the IPv6 loopback adapter on port 6165 (see . However, our network infrastructure isn't upgraded to IPv6, so I need a data publisher running IPv4 to allow subscriptions from other applications. Running a data publisher for the OpenPDC manager and a separate data publisher for applications seems to make sense in this scenario.

I tried to accomplish this by creating a new custom action adapter to instantiate an instance of TimeSeriesFramework.Transport.DataPublisher. I passed this connection string to the adapter "port=6166;interface=". Unfortunately, that didn't work and I got an error that said "Only one usage of each socket address is normally permitted." When I looked into the DataPublisher class, I found that command channel's connection string is hard coded to be "port=6165;". However, it looks like the DataPublisher will pass parameters from the connection string into a separate UDP data channel, if the DataPublisher is configured to run a separate data channel. This has me wondering, is there another way to run more than one data publisher? Am I approaching this problem incorrectly?

Aug 5, 2011 at 6:06 PM
Edited Aug 5, 2011 at 8:08 PM

You are going down the right path!

The hardcoded value is simply the default value to use if no other value exists in the configuration file.

Since each publisher can become a data source for many clients its socket based configuration is stored in the config file so that it can't be accidentally changed by a database update.

Note that the adapter name will become the section in the config file used to specify settings.

Hope that helps!

Aug 12, 2011 at 7:52 PM

Thanks for your help Ritchie. In case anyone else runs into this issue, it turned out that the second data publisher was unneccessary. Changeset 69580 fixed a bug in the openPDC manager which allowed the openPDC manager to be forced to run IPv4. Now, everything seems OK when I enter this connection string for the node's remote status service URL: Server={;interface=};datapublisherport={6165;interface=}.