Hello,
I am trying to test a new configuration with StreamSplitter. Currently, I have a connection configured as follows ; that’s work fine:
StreamSplitter connects to SOURCE_SERVER to retrieve the source data.
StreamSplitter relays (pushes) this data to DESTINATION_1_SERVER (an external server).
In parallel, on the same server, I have openPDC also connecting to the same external data source (SOURCE_SERVER) and port that are used by StreamSplitter. This works, but it results in two connections to my source server, and I would like to have only one connection, that of StreamSplitter.
So, I would like to add an additional destination in the current StreamSplitter configuration:
In addition to Server B, I want to add my localhost on port 4712 as a destination.
Then, configure the local openPDC to receive data pushed by StreamSplitter as a listener.
The StreamSplitter configuration I tested produces the following chain:
sourceSettings={transportProtocol=Tcp; interface=0.0.0.0; server=SOURCE_SERVER_IP:4712; phasorProtocol=IEEEC37_118V1; accessID=1}; proxySettings={protocol=Tcp; interface=0.0.0.0; server=DESTINATION_1_SERVER_IP:4712,localhost:4712; useClientPublishChannel=true}; enabled=True; name=CONNECTION_1
The localhost openPDC configuration is as follows:
transportprotocol=tcp; server=localhost; port=4712; interface=0.0.0.0; islistener=true; maxSendQueueSize=-1
However, this does not seem to work:
The configuration frame metadata appears to be received correctly (PMU are listed in the openPDC Console) when the connection initializes, but the measurements are not received.
Both the StreamSplitter and openPDC Consoles do not show any errors.
Unfortunately, I am forced to use version 1.1.7.0 of StreamSplitter, and upgrading this component is not an option at the moment.
Is this a configuration error on my part?
Thanks a lot for your help,
Regards !
I do not see any immediate issues with your connection string format. Can you let me know which version you are testing? I will see what I find.
Thanks,
Ritchie
Oh sorry, was in the title… will check.
Hello Ritchie,
Thank you.
If it can help, I’ve tried the following test :
- Added to the working string the localhost:4713 destination ; then clic on 'apply on the StreamSplitter GUI.
sourceSettings={transportProtocol=Tcp; interface=0.0.0.0; server=SOURCE_SERVER:4712; phasorProtocol=IEEEC37_118V1; accessID=1}; proxySettings={protocol=Tcp; interface=0.0.0.0; server=DESTINATION_SERVER_1:4712,localhost:4713; useClientPublishChannel=true}; enabled=True; name=CONNECTION_1
- Configure PMU Connection String to listen on localhost:4713 ; then clic on ‘Connect’
I’ve tried the various “Send Config Frame” command without success.
Here are the logs from StatusLog of StreamSplitter :
- on a first time I have the error message in red ; but it’s a ‘common’ one as usually the connection is still established a few seconds after ; even with more common configuration.
- on a second time the green message confirm that the connection is initialized ; but no data are send to / visible in PMU Connection Tester. It’s like the config Frame is never send to the localhost:4713 destination.
- the yellow messages are uncommon in the statusLog file ; at least at this ‘high’ occurence : they are continuously repeated in the log file ; as long as I maintain the dual destination for streamsplitter :
Maybe it can help …
I can confirm multiple TCP server addresses, as in a primary, secondary, etc., were not properly supported until version 1.1.13. Even so, in this case the idea is try to connect to the first IP, if this fails, move on to the next.
Your mode appears to be defining a reverse typical connection and I suspect you want both targets to be on at the same time? If this is the case, I don’t think the code will accommodate that use case as-is – regardless of version.
However, you should be able to create a new stream splitter connection that takes the incoming stream and splits stream to a local TCP proxy - this way other splitter connections, as many as needed, can connect to that local TCP proxy, then individually send data in a reverse connection fashion to multiple destinations – I suspect that will work fine, even in v1.1.7.
Let me know if this helps!
Thanks,
Ritchie
Thank you for your answer.
Yes, I want on SERVER_1 to pull the PMU Data from a front PDC server ; and then send that data (“duplicated”) :
- to a local openPDC (on SERVER_1) for using them with custom adapters
- to a remote openPDC (on SERVER_2) for other usages (actually I’m using StreamSplitter to connect to the front PDC SERVER and relay the data to SERVER_2).
SERVER_1 openPDC and StreamSplitter are both connecting to the same port on the front PDC server (through a FW) ; so that there are two connections. II’d like to only have one connection (StreamSplitter grabbing the data through the FW), then pushed them to the local SERVER_1 OpenPDC and the distant Server_2 OpenPDC.
The historical representation of StreamSplitter (with two branchs) let me think it was possible ; but I understand that it’s only for failover :
I’ll take a look at the TCP proxy solution (Ncat for exemple) ; hoping it will be enough strong to handle with the realtime constraints. Thanks for the suggestion !
