Reverse Connection with GEP?

Hi,

I was looking at this documentation for STTP: documentation/docs/reverse-connections at main · sttp/documentation · GitHub

The long and short of it is that we’ve ended up needing to use GEP instead. Can a similar reverse connection arrangement be made using GEP?

Thanks for your time,

Jake McManus

Well, technically that’s an STTP-only feature - we typically haven’t backported new features to GEP.

Anyway we can update / sync-up versions of your software and get switched to STTP?

Not sure what the options are for your deployment environment.

Thanks,
Ritchie

What are the latest versions of openHistorian and openPDC that work together? We’ve updated to the latest for both, openHistorian v2.8.157 and openPDC v2.9.148, but it sounds like they won’t be able to talk to each other using STTP? Should we revert to openPDC v2.8.196?

Latest versions, i.e., openHistorian v2.8.157 and openPDC v2.9.148, should work fine - sorry, were you having issues with these later versions?

I presumed form a prior discussion you were having trouble with an old openPDC.

Thanks,
Ritchie

Hi Ritchie,

Yes, we’re using the newest versions now. We upgraded recently. We’re still getting the same errors when trying to use STTP, including while using the “version = 1;” flag in the command string.

Thanks for your time,

Jake

Now that you are on latest versions with both openPDC / openHistorian, let’s try this:

(1) Change openHistorian protocol to Streaming Telemetry Transport Protocol
(2) Set the connection string as follows (no version details):

interface=0.0.0.0; useSourcePrefixNames=false; compression=true; autoConnect=true; securityMode=None; server=127.0.0.1:7165; internal=True; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE True}

Hi Ritchie, Thank you, I’ll give that a try.

I also had a follow up question, would it be possible to use STTP to connect two instances of openPDC in the same way? Suppose I had a production environment and a development environment on two different machines, could the development openPDC subscribe to the production openPDC over STTP?

Thank you again,

Jake

Most certainly - that is a common use case. However, is this for the same data or different data?

If you need unique names conflated in the subscriber, then you might need to set useSourcePrefixNames=true

Just let us know and we’ll try to guide your use case as best we can…

Thanks,
Ritchie

In our case, we’re trying to mirror the data from one development machine to the other using an STTP connection between the two.

interface=0.0.0.0; useSourcePrefixNames=true; compression=true; autoConnect=true; securityMode=None; server=[the publisher’s IP]:7165; internal=True; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE True}

I implemented the connection string above, but this is what I’m getting in the openPDC console on the publisher machine.

Can you check ErrorLog.txt for more detailed stack trace around these errors?

Thanks,
Ritchie

Here’s what I found:

(Outer Exception)
Date and Time:         10/19/2022 5:18:17 PM
Machine Name:          [redacted]
Machine IP:            [redacted]
Machine OS:            [redacted]

Application Domain:    openPDC.exe
Assembly Codebase:     D:/openPDC/openPDC.exe
Assembly Full Name:    openPDC, Version=2.9.148.0, Culture=neutral, PublicKeyToken=null
Assembly Version:      2.9.148.0
Assembly Build Date:   3/31/2022 8:11:54 PM
.Net Runtime Version:  4.0.30319.42000

Exception Source:      
Exception Type:        System.InvalidOperationException
Exception Message:     Data publisher encountered an exception while receiving command channel data from client connection: Array dimensions exceeded supported range.

---- Stack Trace ----


[10/19/2022 5:18:17 PM] (Inner Exception)
Date and Time:         10/19/2022 5:18:17 PM
Machine Name:          [redacted]
Machine IP:            [redacted]
Machine OS:            [redacted]

Application Domain:    openPDC.exe
Assembly Codebase:     D:/openPDC/openPDC.exe
Assembly Full Name:    openPDC, Version=2.9.148.0, Culture=neutral, PublicKeyToken=null
Assembly Version:      2.9.148.0
Assembly Build Date:   3/31/2022 8:11:54 PM
.Net Runtime Version:  4.0.30319.42000

Exception Source:      GSF.Communication
Exception Type:        System.OverflowException
Exception Message:     Array dimensions exceeded supported range.
Exception Target Site: SetReceiveBuffer

---- Stack Trace ----
   GSF.Communication.TransportProvider`1.SetReceiveBuffer(size As Int32)
       openPDC.exe: N 00021
   GSF.Communication.TcpServer.ProcessReceivePayloadAware(args As SocketAsyncEventArgs)
       openPDC.exe: N 00322

That’s interesting - this is coming from the socket layer.

Something is a-miss - I think we’ll need to dig a little further - it could be there’s an “old” STTP DLL floating around in your system. Can you enumerate, on the publisher, what are all the *sttp*.dll type files?

Perhaps on the subscriber system as well…

These are the search results for the publisher machine:

Subscriber machine:

I did not find any sttp files on the C: drives of either machine, for completeness.

Thanks Jacob - hoping this is something simple - maybe a quick Teams call would be the more simple solution if that is an option.

Want to send an e-mail to check availability?

Discussion update:

openPDC Manager UI, which uses GEP, was accidentally configured to connect to STTP port - hence causing errors.

STTP between systems now working fine.