Handling Extra Messages
If you mean like a server sending updates, im afraid youre going to have to reduce the quality, at least for some of the clients (if you have more important clients, like ones with a membership)
Possible solutions:
-Reduce non-necessary packets (fewer position updates, fewer 'visuals' updates...)
-Activate a laggy compressor to make the packets smaller by sacrificing some CPU under low bandwidth
-Slow down the simulation speed (depends what youre working on)
[source]
if(m_updateMessages.Count * messagesize < m_bandWidth * 3.2f)
{
m_updateThresh = Mathf.Lerp(3.2f,0.2f,1.0f / (m_updateMessages.Count + 1.0f));
}
else
{
//shutdown. Too laggy.
}
[/source]
this only currently handles update messages though so messagesize is constant.
This happens after the messages are processed so the count would be excess messages that bandwidth couldn't handle.
Is this a decent solution, or should I try something else?
If you need to send more data than the network can tolerate, then you will fail, and you might as well disconnect the users.
If you don't need to send the data, then why are you sending it?
The main challenge is to reduce the number of messages you need to send; the secondary challenge is to reduce the size of each message you send.
No matter what you do, you have to be prepared for falling behind. The available bandwidth may at some point go close to zero, for various reasons (none of the good,) and you need to know what to do in that case. Typically, send a message to each connected client that there's a problem, and then disconnect all users.
Oh, and send email to the pager of whoever runs the servers to have them wake up and look into it, as they weren't on the ball as available bandwidth was starting to go down :-)
The code above will decrease messages sent up to 16 times before I shutdown or start booting players.
Decreasing the rate you send messages isn't going to help if you still generate messages faster than you can send them.
You have to decrease the rate at which you *generate* those messages. For example, do not generate a new update for an entity if the previous update for that entity is still pending in the queue -- that would auto-balance the network to send no faster than it could support.
The next question is: what do you use as an indication that you "can't send" a packet? Are you using TCP or UDP? If UDP, then your local network interface can send messages very quickly without blocking, but those get dropped as soon as they hit your upstream cable modem / DSL router / ISP interface if you exceed capacity.
