Serialization of TCP socket establishment for connections on a Circuit

Paul will also write up the problem statement with all the detail we have so far, and suggest to the customer and the radio vendor that they take another look at the field equipment

There was some code provided in the past, and was attached to SEROGXI-269 which was for Shell, who no longer need it as they have migrated to MQTT. Knowing a little bit about Shell and their custom TCAP protocol, it is no surprise they needed something like this.

Thanks Dean - I agree that this will be a project effort.

If it's not going to be added to baseline, I think it's up to the project delivery team to decide how they want to handle this request in the future. I'd contact Randy, Clay, or generally, Paul for comment.

Also to consider is Omnicomm supports a Front-End-Processor functionality which, if should allow a developer to write code that handles the connection for Omnicomm by providing an API that Omnicomm uses. This is used for things like 3rd party mandatory libraries that are blocking, but also for initializing radios and such. In that case, this FEP functionality could be used to implement something that would throttle connections but otherwise pass connections through relatively unchanged.

Hi Dean,

I've asked Collin from our extensions team to think of some options that are outside of the product. Please review and then lets discuss.

I see a few options, but none of these are as elegant as a product solution. These will seem a bit like a kludge at first, but there is nothing inherently unstable about these and in time they could feel rock solid.

In all cases, I would see Omnicomm connecting to a socket pass-thru program of some sort that then manages the connections to the end devices in a throttled manner. I present a few options of this solution below. I am assuming 1000 devices with 1000 unique IP addresses.

N to n forwarder

Perhaps the simplest to think of, is a socket pass-thru that opens one port for each device that needs to connect (e.g. 9000-9999). This pass-thru allows a maximum number of connections per period (second?). When it receives a connection on one port (e.g. 9000) it connects it to some remote address (IP and port). This could even be configured in the database as an extension of the remote record. So we would configure the remote to connect to localhost:9000, but another field would point to the remote IP and port. When the pass-thru receives a connection from Omnicomm, it doesn’t have to accept right away, so it can pause, then connect to the remote device, and only accept the incoming connection once it has successfully connected. So connection timeouts would need to be increased (probably quite a bit – maybe several minutes in cases).

Cons: Lots of open ports on the local machine, but if we are talking about 1000, it is manageable (talk to me about OPC UA). Needs to be coded well to handle 1000 connections in a single process without blocking any of them.

Pros: Works with any protocol (perhaps a few exceptions with UDP).

Protocol Aware Forwarder: 4 to n

If protocol aware, assume Modbus for instance, you could throw 250 devices on a single network (total four) and have it connect to the socket pass-thru. The pass-thru, based on device address, would know which remote IP to connect to and send the poll out to. It could connect in the order the polls arrive, but once it has hit a certain threshold it could not respond to Omnicomm until later when the connection is established. Then normal no-reply handling would kick in. Again, the config could be thrown in the database if desired.

Cons: Protocol specific, need to assign unique device addresses to devices, needs to be coded well.

Pros: Uses fewer sockets.

Use Existing Omnicomm throttling of Modem Pools: m to n

Omnicomm has this functionality built in – modem pools. In fact, in another product I used the Modem Pool concept to throttle connections to IP devices. Suppose Omnicomm was given 50 “modems” in one “modem pool” – but all 50 pointed to this socket pass-thru (via 50 sockets). It would then be throttled to 50 connect attempts at a time automatically within Omnicomm. The “phone number” could be configured as the IP address and port, then the socket-pass thru would see something like “ATDT192.0.0.1:2001” and it would know which remote port to connect to. It could cache connections and remain connected rather than disconnecting on an ATH, or it could disconnect, whichever is preferred.

Cons: Not many, but feels weird. A bit tougher to code, but not much. Is Omnicomm modem pool functionality all that reliable?

Pros: Uses existing Omnicomm functionality to throttle which reduces strange timeouts an no-reply situations discussed above, configuration is in a much more “natural” location. It is basically integrated better.

All-in-all, if we trust Omnicomm modems, the third solution is probably the one I would go with because OASyS would be in control and aware of the delays and timeouts. If there is doubt about Omnicomm, then I would probably go with the first solution, it is a straight forward port forwarder - but there would be unusual delays at times.

Further updates from Dean:

There is no OASyS 2018 version in the mix. Customer was initially on DNA 7.4, and upgraded to DNA 7.7 Elk SP5 years ago. They are planning their next upgrade to ES2023+, with the project expected to start in Q4-2023, which means they should plan to take ES24 before FAT, making ES24 the actual target for this enhancement.

The provided code was merged into DNA 7.7 Elk SP5 to address an issue caused by a recent move from leased line and serial communications to an Ethernet master radio. The issue results in sporadically knocking out 40+ sites in the distribution network.

Targeting Q4 2023.

If code was provided for 2018, then this is a longer-term future need. Any idea of the Year in which EBMUD will upgrade again?

This will need to be optional - should it be optional at the connection/circuit level, or at the Omnicomm level?