What is the purpose of having two publishers? In other words, is the data redundant between the two publishers or partitioned? Are you looking to set up something like a fail-over connection or a redundant connection?
Hello Stephen,
Please see my below requirement:
I have 2 testing instances of openHistorian (running inside corporate firewall) and both are connected with PMU and I want to subscribe both pdc(s) from one cloud VM to monitor both PDCs.
E.g.
Machine-A, it’s a cloud VM running with OpenHistorin
Machine-B is PC running with openHistorian and connected with PMU
Machine-C is PC running with openHistorian and connected with PMU
Here B and C is inside the corporate firewall.
Now I want to see the timeseries data of both Machine-B and Machine-C in Cloud VM (Machine-A).
According to this requirement,
What is the solution in openHistorian?
Is this requirement correct?
If this requirement is not correct, then how user can see all PMU units timeseries data through single PDC?
Moreover I would like to know the real-time topologies for OpenHistorian, if you have any documents related to these use case, please help.
Thanks & Regards
Logu
Ah, I see. With both B and C behind the corporate firewall, they share the same public IP address. In that case, you will need to put the publishers on B and C on different ports. This can be accomplished using Network Address Translation (NAT) in the corporate network’s firewall to map an external port (for example, 6178) to an internal endpoint (for example, Machine-C:6177).
It shouldn’t be necessary to do this, but you can also change the publisher port in the openHistorian configuration file (openHistorian.exe.config) by stopping the service, locating the /configuration/categorizedSettings/tlsdatapublisher/add[@name=ConfigurationString] setting, changing the port value, then restarting the service.
Thanks,
Stephen
Hi Stephen,
Thanks for your information.
I have some queries about PDC Subscription/Publishing concepts in OpenHistorian, please clarify.
In OpenHistorian Manager, we’ve below list of subscription options
- Input -> Create Internal Subscription
- Input-> Create Authorization Request-
- TLS
- Gateway
Queries:
When should I use an option “Input->Create Internal Subscription”?
My understanding is, if both subscriber and publisher are located within same corporate network, then “Input->Internal subscription” will be suitable. So please correct me, if my understanding is wrong.
When should I use an option “Input->Create Authorization request”?
My understanding is, this option is also used to perform subscription with publisher, which is located anywhere (within corporate network or external network - Cloud). Please correct me if I’m wrong.
Here,
An option (a) TLS mode, will be used with SSL certificate to perform the secure communication.
This can be applicable both within internet (corporate network) and connect from public network to corporate network (anywhere)
- An option (b) Gateway, what is the purpose of this option? How does it differ from “Input -> Create Internal Subscription”? or both are same?
- When should I use an option (b) Gateway?
Additional Query:
Could you please explain logic of Subscriber/Publisher mechanism of OpenHistorian?
Especially for TLS publishing
- Publisher is listening port 6177
- Subscriber is connecting to PublisherIP:6177
- Performs certificate authentication and connection gets established.
My query is:
All data transmission is happened through only TCP port 6177 or any other port is getting involved?
Please explain all transaction details, so that I can make better documentation with all configuration details like port enabling with firewall and etc…
Please kindly clarify.
Internal subscriptions are intended for trusted network paths in which authentication, encryption, and ACLs are considered to be unnecessary. It merely simplifies the setup of the gateway connection for transfer of data on an internal network or VPN by eliminating the certificate exchange, subscriber authorization, and subscriber measurement access steps of the configuration. Instead, all the requested data is automatically forwarded to any subscriber that can reach the publisher’s internal port (6175), and the subscriber can choose to filter the data set down to what it needs using filter expressions. For example, this type of gateway connection is used extensively by the visualization tools in openHistorian Manager, which does not need to be authorized since it exists on the local system.
The Gateway option on the Inputs > Subscription Based Inputs > Create Authorization Request page should never be used for anything. This is a legacy option that has long been deprecated, and we’ve recently dropped the option from the STTP standard (IEEE P2664) that is based on GEP.
All data is, indeed, transferred over the connection made by the subscriber to publisher port 6177. The only exception to this rule is if you select the options to transfer data over a separate UDP port instead. This option is typically not recommended, as the compression options for UDP are not as good as they are for TCP. However, if you do select this option, data packets will be sent from the publisher to a UDP port on the subscriber system. This is a unidirectional UDP data stream so the publisher expects no UDP return packets.
Thanks,
Stephen
Hello Stephen,
I’ve raised a query separately “OpenHistorian Archive file reading/writing programmatically”, please kindly help asap.