Handling Protocols that require fixed communication coordinates?

[chrisdutz]

Giving GitHub Discussions a test-run on this one ;-)

So I noticed several times, that we have some drivers, that require fixed communication coordinates. For example ADS Discovery requires the driver to open a UDP listening socket on a given port, BACNet also seems to rely on this. However in contrast to Discovery being handled on Driver level, BACNet needs this on a connection level (So the communication runs via a fixed port and the connection is identified either via a connection id or with a response-id that matches a request-id). In Profinet we have both the problem of the ADS Auto-Discovery but also the problem that we can only once open raw sockets. This would prevent us from communicating with multiple PROFINET devices, which would suck.

So we need to come up with some transport that can handle multiple connections with only one network port, ethernet device or serial port.

Cesar correctly brought up the fact that we shouldn't be using "static" stuff as this breaks all dynamic reloading in OSGI environments.

I think using the Driver itself as the root for such a shared communication channel sounds like the best thing to do. It will solve the problem of shared network connections without breaking the OSGI reloading.

However it will not help with shared Serial ports of raw network access, as we could have PROFINET and mabe one day EtherCAT running on the same system. I would assume both to require raw sockets ... or if we have a RS485 port and both a Firmata and a Modbus RCP device on it ... but admittedly on this use-case I would simply say: "Buddy ... you were asking for trouble in the first place, now live with it" ... With the Raw network stuff ... I think we should be able to come up with a way to share this ...

[splatch]

I am not entirely sure what you mean by fixed communication coordinate - a network/serial/raw socket and access to it or static addresses?

For first we could have a multiplexing layer if we would netty internals and limit transports to rely only on input and output streams (or buffers). It won't be easy since access to buffers is down to byte and not message level, plus we would need to understand received packets before routing to internal receiver. Going that route is difficult as it requires redesign of transports but also making protocol frame detection logic re-usable elsewhere.

Back at the time when I was messing with ADS discovery I made a separate UDP listener/emitter which was singleton started aside of driver. This listener provided methods to register packet listeners and emitter allowed to send outgoing message. I did revisit this design recently and generalized it even further to a broadcaster and requester, each having a bit different signatures but ultimately relying on some sort of destination address and byte[] sent (or received) from it.

Use of statics is no-go for OSGi for sure, however many of its pitfalls can be avoided with basic interfaces which can be implemented according to OSGi runtime needs.

[chrisdutz]

Well for example BACNet seems to require the client to operate on a certain port ... same with Profinet (even if I'm not 100% sure with that). But I think the problem sort of also applies to Serial transports (well RS485 or so ... as RS323 is only between two devices). In general I think it can only affect UDP, Serial or Raw transports.

I guess the things we can assume: One serial port or udp port will only support one protocol. And that running multiple instances (multiple VMs) is also out of scope. For Profinet and BACnet we'd need this in order to have "connection" to multiple devices at the same time from the same application.

I'm sort of thinking of separating the Transports from the Drivers by another layer ... one the driver asks to create a connection. This could then keep track of things ... so if we request a simple UPD "connection", we'd get a fixed remote port and a random local one. But if we provide both local and remote coordinates, the transport factory could create a new instance on the first request and then reuse that as soon as a second request for the same local coordinates comes in.

[splatch]

There are options such SO_REUSEADDR which in theory should help, with at least part of the problem. Sadly, this applies only to network sockets and will not help with serial nor ethernet level access. Making further thought on transports will definitely not harm them.

Making one serial port using more than one protocol will heavily depend on protocols themselves, its possible but in order to work both protocols must have a clear start and termination sequences, otherwise it will lead to conflicts.

[chrisdutz]

And it seems to only apply to broadcast sockets (At least I think I remember that Sebastian said something like that) ... or that's just something where it's different in go.

[sruehl]

yeah tripped over that a while ago libp2p/go-reuseport#93