What I created: client connects to server, then player input is being shared between them.
I only send data when there’s input. And do not send anything if there’s no input.
Everything works ok if there’s some input happens periodically. But when there’s no input (an therefore no data sends) during about 20 sec, the connection disconnects.
I didn’t find any timeout related times neither at NetworkConnection or UdpCNetworkDriver classes.
So, why does the connection disconnects? Can I somehow ask it not to? Or I have to send dummy data periodically to avoid disconnection?
Just as you’ve guessed, for each connection that the UDP Network Driver has, it stores the last package received and the time it receives it. Then it checks that time every update to see if it should disconnect the connection.
What you need to do is to instead of specifying no NetworkParameters when creating the NetworkDriver like this:
m_Driver = new UdpCNetworkDriver(new INetworkParameter[0]);
you instead do something like this:
m_Driver = new UdpCNetworkDriver(new NetworkConfigParameter{disconnectTimeoutMS = 30000});
You need to do this with both the server and the client, because either one will disconnect if the timer runs out.
PS: 30*1000 = 30000 is the default parameter, so you need to increase this number if you want it to delay further before disconnecting.
Generally you want to send packets on a fixed interval, say 30 times/sec in a game, even if there’s nothing to send (which should be pretty rare) just submit an empty packet to the remote.
This is what I ended up doing as well. I just send a short message saying ping every 1s and the server replies pong. Thus keeping the connection alive that way. I didn’t increase the timeout either.
Yea, sending stuff periodically seems reasonable, since the absence of incoming data can be interpreted as lost connection and measures can be undertaken.
Not just for this API, but since UDP is a connectionless protocol network infrastructure like NAT routers will time out port mappings in their translation tables after a fairly short period of time (often 30 seconds or less). My approach is to monitor when the last message was sent, and if 3 seconds have passed to send a keep alive message.