Shared UDP Listener

[Julusian]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

Some devices (eg VISCA over UDP) send data back to Companion over a hardcoded port number. On some devices this can be configured on the device, but on others it cannot be changed from the default.
This results in only being able to use one instance of these VISCA modules at a time, as they will all try to bind to the same port which is not allowed in nodejs/the os. It is possible to bind to the port in a shared fashion, but only one of the instances will receive all the packets for all cameras.

To allow for this to work properly, Companion could act as a 'broker' for these sockets. Modules can request companion to open a 'shared udp port', and it can then forward received packets to every instance that has requested that same shared port.

Some thought will need to put into what properties to expose for the socket, as anything exposed will always be chosen by the first module to launch (it could be a different module on every launch).

Q) Should instances be able to send packets from this socket, or just receive? I would be tempted to just allow receiving to begin with, sending can be added once it is proven useful.

In the future we may want to add some way to filter what packets to send to each instance. This could definitely be a follow up as it is solely a performance optimisation.

Usecases

No response

[goseid]

Just receiving packets from that socket would be fine for Sony cameras using VISCA. It doesn't matter what port originates the exchange they will always respond to port 52381 but can be reached from any UDP port.

In order to determine what device the instance is communicating with, when the module opens a 'shared udp port' it could include the IP address it wants to receive data from and the broker could filter out all other traffic and just send responses that originate from the subscribed IP.

Alternately, the broker could pass the data received and the IP address it received the data from so it can be matched with the host from the config of the instance and filter out data from other IPs. This would seem to send unnecessary data to all instances though.

[goseid]

Is this functionality that could be added to UDPHelper by passing an optional argument rather than a new construct?

[Julusian]

Oh good point. I was thinking filtering would need to parse messages, but doing it by ip address would be really easy and would cover most cases

[krocheck]

Yeah, this was on my list about 4 years ago, this exact thing, but fell off. Basically the module would register a port and IP address with the handler and the handler would spin up the port and handle the routing based on the IP address from the module. I planned for it to be send and receive, but receive only would be fine with me. I figured tx and rx only because we have a common tx module for OSC already, so its not bizarre to have that based on what we already have deployed. I would think being able to define generic UDP or OSC for the receive would be handy.

[elianterelle]

Any updates on this? As the CX350 module depends on this, i'd be willing to help implement this, but i might need a few tips on where this would best fit into the companion core, as i don't know that much about its architecture.

[Julusian]

There is an implementation of this available to test in v3.3 beta 6759 and later.
You will need to use @companion-module/base v1.8.0-0 (or newer), where you will find a createSharedUdpSocket method on your instance class that you can use for this.

The api of createSharedUdpSocket and the type it returns is designed to be a subset of what is possible with the nodejs dgram api, the hope is that it can be a drop-in replacement for the normal lib.
There is a chance this could change (or be dropped if there are terrible flaws in this approach) before the release of 3.3.0, but I don't expect so

In my limited testing it all worked as expected, let me know if you encounter any issues.

For now every received message is being routed to every module listening on the socket, in future builtin filtering could be added. And it is possible to send from this socket, although Im not sure how useful that will be in practise.

[goseid]

Thank you for your work on this. I'm able to get the responses from multiple cameras as hoped.

Is the intent to use this along side UDPHelper or in place of it? In my initial testing I was using UDPHelper to send and just using createSharedUdpSocket to listen for responses from the camera. That was easy and worked well but I'm curious if I should be using the shared socket for sending as well.

[Julusian]

Glad to hear!

That is up to you, either way is fine by me so choose whatever works best or makes the most sense for you use case/module