nmos-cpp
nmos-cpp copied to clipboard
sony
Events Receivers - don't stay connected
Running on Windows.
- Start the registry
- Use Riedel NMOS Explorer 1.5.5 to monitor the nodes and other objects
- Start the nmos-node sample program
- For the data sender, use nmos explorer to turn the sender on. Should turn green
- In nmos explorer, drag data sender to data receiver. Receiver should turn green.
- Put breakpoint in make_node_implementation_events_ws_message_handler where the temperature event is being handled. About line 338.
- When the breakpoint is hit, wait a few seconds until the nodes disappear from the nmos explorer.
- Remove the breakpoint
- Hit continue
When the nodes come back, the data sender is green, but the data receiver is not. (usually) For the video sender/receiver pair, the video receiver usually comes back green.
Is there something missing for the data receivers that the connection info is not maintained as it is with the video sender/receiver pair?
I suspect this is a known spec, or QoI issue for connection-oriented protocols with IS-05, as opposed to connection-less ones like RTP. Basically the spec says that it's up to the implementation how many times to retry when a connection breaks before signalling that it's broken via master_enable / subscription.active.
The relevant passage of the IS-05 spec is here: https://github.com/AMWA-TV/nmos-device-connection-management/blob/v1.1.x/docs/4.0.%20Behaviour.md#connection-status
On the implementation side see here: https://github.com/sony/nmos-cpp/blob/8b8b269ff9e5d33d8e1b27ec2dec82e84f813b11/Development/nmos/connection_events_activation.cpp#L134-L138
Opinions/contributions on improvements to how this is handled are welcome!
Many of the embedded systems I have worked on have clients retry forever to reestablish a connection to their server. An error message can be logged but the device is not going anywhere and just continually tries to reconnect. We typically try once a second. The devices might have at most a dozen or so connections.
This might not be appropriate in all cases but it seems like it should be a possibility.
Agreed.
Retry probably ought to be configured with similar min/max/backoff-factor properties as DNS-SD (plus whether to ever give up completely).
I heard another data point of IS-07 panels with upwards of 500 Senders/Receivers.
The IS-07 events will add a lot more connections. (would MQTT reduce this?)
Our worst case would probably be a single physical device with about 100 signals where each signal has one audio receiver, 4 event senders, and 5 event receivers. I am not sure that all would be exposed via NMOS at the same time but they could be.
(would MQTT reduce this?)
It depends on connection patterns.
IS-07 recommends a WebSocket server endpoint per Device or per Node rather than per Sender, which means that making a lot of connections from one Node's IS-07 Receivers to another Node's IS-07 Senders can be achieved with a single WebSocket connection.
If a Node has Receivers which are to be connected to Senders of many different Nodes, then MQTT would result in fewer connections overall.