I've made a few changes to my MP game, and upgraded to the latest SFS version. Now I am suffering from connections being regularly dropped and all I have to go on is this in the server log:
INFO | jvm 1 | 2008/02/07 09:46:31 | 09:46:31.343 - [ INFO ] > Too many dropped messages. Client will be disconnected: ahrweave, 11
INFO | jvm 1 | 2008/02/07 09:46:31 | 09:46:31.343 - [ FINE ] > Disconnecting 1 dead channels.
Any ideas what would cause the dropped messages? The server is undergoing some strain from another application. Might this cause it?
Ta,
Dead channel and dropped messages
Re: Dead channel and dropped messages
drpeck wrote:I've made a few changes to my MP game, and upgraded to the latest SFS version. Now I am suffering from connections being regularly dropped and all I have to go on is this in the server log:
INFO | jvm 1 | 2008/02/07 09:46:31 | 09:46:31.343 - [ INFO ] > Too many dropped messages. Client will be disconnected: ahrweave, 11
INFO | jvm 1 | 2008/02/07 09:46:31 | 09:46:31.343 - [ FINE ] > Disconnecting 1 dead channels.
Any ideas what would cause the dropped messages? The server is undergoing some strain from another application. Might this cause it?
Ta,
If only one user have the problem is most likely the problem to be caused of that the user have connection problems.
potmo wrote:can it be that you have modified the config-xml to be more kind to dropped messages and after the update it's overwritten?
I must say that's option that didn't come me in mind
Also depends which is the previous version of SFS - I think the disconnection due to dropped messages was added recently.
Have you noticed this in the config.xml?
You can fine tune the dropped packets settings by allowing a higher threshold and queue size. Be sure to consult the docs (chapters 2.1, 2.2) for more details
Code: Select all
<ClientMessagQueue>
<QueueSize>80</QueueSize>
<MaxAllowedDroppedPackets>10</MaxAllowedDroppedPackets>
</ClientMessagQueue>
You can fine tune the dropped packets settings by allowing a higher threshold and queue size. Be sure to consult the docs (chapters 2.1, 2.2) for more details
drpeck, how did it go? I faced frequent disconnections too after upgrading to latest SFS version 1.6.1 and was forced to go back to 1.5.5 as trying to increase the <QueueSize> and <MaxAllowedDroppedPackets> did not go smoothly for me. The values kept getting higher and higher.
Btw, for my case the disconnection occurs to not only one user but a group which results in mass disconnection. I've been told to send less messages per second and set logging level to lower to catch more details. I'm just checking if you're facing the same issue as me
Btw, for my case the disconnection occurs to not only one user but a group which results in mass disconnection. I've been told to send less messages per second and set logging level to lower to catch more details. I'm just checking if you're facing the same issue as me
Limited success
I've had some success with
<DeadChannelsPolicy>normal</DeadChannelsPolicy>
and
<ClientMessagQueue>
<QueueSize>120</QueueSize>
<MaxAllowedDroppedPackets>50</MaxAllowedDroppedPackets>
</ClientMessagQueue>
I'll let you know if I solve it. I had been blaming a dodgy wireless connection, but subsequent tests are shown it occurs in almost every type of broadband/8Mbit Fibre Leased Line so I think it is possibly due to the high demand I'm putting on the server.
<DeadChannelsPolicy>normal</DeadChannelsPolicy>
and
<ClientMessagQueue>
<QueueSize>120</QueueSize>
<MaxAllowedDroppedPackets>50</MaxAllowedDroppedPackets>
</ClientMessagQueue>
I'll let you know if I solve it. I had been blaming a dodgy wireless connection, but subsequent tests are shown it occurs in almost every type of broadband/8Mbit Fibre Leased Line so I think it is possibly due to the high demand I'm putting on the server.
A comment on this: even if you have plenty of super high quality bandwidth the problem could be the client connection.
If the client network "pipe" is not capable enough, messages will go down slowly and finally accumulate on the server side. When this "accumulation" passes the configured threshold the server will shut down the connection.
The first thing to do is monitoring your bandwidth in order to check that the problem is not on your side.
It's also helpful to measure how much data is being sent from/to the client and see if you can find situations in which too many packets are sent in too short time.
Finally gather user feedback and see what's the average connections speed of those who complain about problems.
With these 3 elements you should be able to have a better understanding of where the problem could be.
If the client network "pipe" is not capable enough, messages will go down slowly and finally accumulate on the server side. When this "accumulation" passes the configured threshold the server will shut down the connection.
The first thing to do is monitoring your bandwidth in order to check that the problem is not on your side.
It's also helpful to measure how much data is being sent from/to the client and see if you can find situations in which too many packets are sent in too short time.
Finally gather user feedback and see what's the average connections speed of those who complain about problems.
With these 3 elements you should be able to have a better understanding of where the problem could be.
Return to “SmartFoxServer 1.x Discussions and Help”
Who is online
Users browsing this forum: No registered users and 32 guests