Connection handling for dropout/bad network

[samgardner]

Hi, I'm wondering if it would be a good feature for the library to internally and automatically try to reestablish a connection to the switcher in the event of network failure, unplugged cabling or a power cut, etc.

I have built my own timer based watchdog wrapped around this library for my application but am thinking perhaps it would be better to be self contained within this library? I can't imagine many users of these switchers not wanting a solid, reliable connection.

Please let me know if I have missed something in the source code, but I could not see any mechanisms like this already in place.

[samgardner]

I noticed that I was receiving the following in my connection watchdog code and found it was coming internally from the library: QNativeSocketEngine::bind() was not called in QAbstractSocket::UnconnectedState

The call to bind() is in QAtemConnection::connectToSwitcher.

I have changed this to the following:

m_socket->bind(m_port, QUdpSocket::ShareAddress|QUdpSocket::ReuseAddressHint);

This seems to have fixed the warning, and also my reconnection issues when multiple calls to connectToSwitcher are called.

I'm not sure if this is the correct strategy but I now have a persistent connection to the ATEM regardless of poor network quality or hardware failure - just keeping you in the loop in case others have this issue.

[petersimonsson]

Hi, sorry for the very late reply. :( There already is a built in timer but it does try to reconnect on its own instead it emits a disconnected signal. So your app only need to connect to that signal instead of implementing its own timer. I'll add support for changing the timeout but currently it's set to 1 second.

[samgardner]

Thanks for the response. I could only find m_connectionTimer, which every 1 second if no data has been received calls handleConnectionTimeout, which emits disconnected. Within the library I can't see anything which connects disconnected back to any reconnection logic. When handleError or handleConnectionTimeout is called, m_socket is closed. I can't see anything that re-opens it or calls connectToSwitcher again. If I am mistaken please point out where/how this is happening.

Does my application need to connect disconnected back to connectToSwitcher? I am unable to re-establish a connection to the switcher if I don't do this in my application. I also can't immediately connect disconnected back to connectToSwitcher, this only seems to work after a 2 second timeout using my own timer.

I also found a related issue which masks some of this connection behaviour. When multiple calls to the API are called when disconnected, it seems there is a big backlog of messages waiting to be sent down the socket. In my application code, I check the connection state and discard the message if currently disconnected. In my testing this seems to allow for a faster reconnection as there isn't a "backlog" of messages trying to swamp the switcher. I am running on a weak raspberry pi system so this may not even be an issue for most users!

Thanks again!

[petersimonsson]

Hi, yes you would have to reconnect on your own when the disconnected signal is emited. I'll see if I can find a solution for you backlog problem.

[petersimonsson]

I commited a possible fix for the backlog issue you got let me know if it fixed your problem.

[dedicatedbroadcastsolutions]

If I read the code correctly, the way it is written, I cannot be connected to the switcher for more then 1 second at a time? This seems like kind of a silly limitation. Isn't it not good to be opening and closing connections that often?

[petersimonsson]

No, the connection will stay up as the switcher will ping the client which will refresh the timer.

[samgardner]

From what I've gathered with these switchers, it seems they continually ping all clients regardless of control signals to the switcher in a ping/pong protocol. I think this is why they have a hard limit of the number of connected clients - Skaarhoj has some figures of around 7 clients for a TVS and around 10 for the Production Studio models. It took me a while at first to wrap my head around this library, but when QAtemConnection receives any socket data from a switcher, it's internal connection timer is reinitialised and started again. If the timer eventually runs out after X seconds, ie. hasn't received a ping for X seconds, the disconnect signal is thrown. What the library doesn't do is try to reconnect automatically, it is left up to you to connect the disconnected signal back to connectToSwitcher.

[dedicatedbroadcastsolutions]

My question then is why was the library not detecting any response from my switcher and disconnecting? When I last tried using this library I could get it to connect and adjust the AUX channels like I needed to, but it would always time out after 1 second. I'm running the original 1 M/E

[petersimonsson]

Could you create a pcap in wireshark or similar of a failed connection attemp?.