Too much Dropped message after 500 connections
Thanks... it's actually a bit difficult to interpret it, do you also have a more detailed view of that day?
As regards your settings they seem okay but evidently your application is doing some heavy broadcast at a certain point, not sure why without knowing all the details. Do you run your own server side code?
If you do can you think of any specific function in your code that updates all the players at once? Maybe you are updating users in for loops?
As regards your settings they seem okay but evidently your application is doing some heavy broadcast at a certain point, not sure why without knowing all the details. Do you run your own server side code?
If you do can you think of any specific function in your code that updates all the players at once? Maybe you are updating users in for loops?
Here is it:Lapo wrote:Thanks... it's actually a bit difficult to interpret it, do you also have a more detailed view of that day?
http://img.skitch.com/20100929-cehyu4xb ... t1d3ch.jpg
On Friday we have tried to increase values "QueueSize" and "MaxAllowedDroppedPackets" to 10000000 and it helps us to avoid disconnections. But we have a big "Outgoing Message Queue Size" now, which jumps from 0 to 3k from time to time.
Yes, I have such function. It updates some data for all users one time per 2 hours then sends updated data to clients.Do you run your own server side code?
If you do can you think of any specific function in your code that updates all the players at once? Maybe you are updating users in for loops?
But "Outgoing Message Queue Size" jumps more than one time per 2 hours. Does this mean that there is not a problem with massive user updating?
The function which is called one time per 2 hours:
and the function which updates client
Code: Select all
function reproduceResources() {
var zone = _server.getCurrentZone();
var room = zone.getRoomByName("Lobby");
var playersArray = room.getAllUsers();
for(var n = 0; n < playersArray.length; n++){
var user = playersArray[n];
var rtimeData = user.properties.get("rtimeData");
user.properties.put("rtimeData", reproduceUserData(rtimeData));
updateRtimeData(user);
}
}
Code: Select all
function updateRtimeData(user){
var stat = getToolToUser(user);
var resp = {};
resp._cmd = EXT_RTIME_UPDATE;
resp.rtimeData = user.properties.get("rtimeData");
resp.instruments = {slaps:Number(stat[SLAPS_TOOL].quantity)};
resp.prices = {slapPrice: SLAP_PRICE, slapPower: SLAP_POWER, realSlapPrice: REAL_SLAP_PRICE};
resp.globalObject = globalObject;
_server.sendResponse(resp, 1, null, [user])
}
Yes, it is called once every 2 hours. Our chat application have few game features (gifts, carma) which can be used in chat several times, then features are blocked. The code I sent restores these features in course of time, so user can use it again.Lapo wrote:You mean it is called once every 2 hours?
Can you explain what it does in short?
I have the same problem with the server, it drops a lot of outgoing messages.
I'm using smartfoxbits as lobby of my games (all games are turn based, like cards games, or domino). The amazing things is the games are not affected by this problem, a match is never interrupted by a lost message, the players are playing and suddenly, one of them is kicked.
This is the message that we get in the log file.
Too many dropped messages. Client will be disconnected: Matias Benitez, 11
It doesn't matter how big do I set the <MaxAllowedDroppedPackets>, there are players that are disconnected from the server.
In fact, we tried to set a ridiculous number in <MaxAllowedDroppedPackets>, like a million. The messages stopped to appears on the log, but the players are still kicked.
Of course.. this isn't happened with all the players.. we have around 8000 players everyday, and about 100 complaints about this, everyday.
In the smartfox admin, we can that the outgoing dropped message is huge.
There is a way to know which are the dropped messages?, and there is a way to avoid the sfs to kick users by dropped message?.
We are using SmartFoxServer Pro 1.6.9, with unlimited connections (but we had this problem using 1.6.6 version too)
And the server hard is,
Operating System: Windows Server 2003 - Standard Edition Processor: Intel Core 2 Duo - 2.66 GHzRAM: 2 GBTotal.
Thanks a lot!!
I'm using smartfoxbits as lobby of my games (all games are turn based, like cards games, or domino). The amazing things is the games are not affected by this problem, a match is never interrupted by a lost message, the players are playing and suddenly, one of them is kicked.
This is the message that we get in the log file.
Too many dropped messages. Client will be disconnected: Matias Benitez, 11
It doesn't matter how big do I set the <MaxAllowedDroppedPackets>, there are players that are disconnected from the server.
In fact, we tried to set a ridiculous number in <MaxAllowedDroppedPackets>, like a million. The messages stopped to appears on the log, but the players are still kicked.
Of course.. this isn't happened with all the players.. we have around 8000 players everyday, and about 100 complaints about this, everyday.
In the smartfox admin, we can that the outgoing dropped message is huge.
There is a way to know which are the dropped messages?, and there is a way to avoid the sfs to kick users by dropped message?.
We are using SmartFoxServer Pro 1.6.9, with unlimited connections (but we had this problem using 1.6.6 version too)
And the server hard is,
Operating System: Windows Server 2003 - Standard Edition Processor: Intel Core 2 Duo - 2.66 GHzRAM: 2 GBTotal.
Thanks a lot!!
One possibility you should check is that your application sends too much data for the average client.In the smartfox admin, we can that the outgoing dropped message is huge.
How do you know that server is kicking them out?In fact, we tried to set a ridiculous number in <MaxAllowedDroppedPackets>, like a million. The messages stopped to appears on the log, but the players are still kicked.
This is highly unlikely, what happens instead is that the connection is lost probably from client side, due to the client traffic issues.
We recommend profiling the network usage of a regular sessions and see if there's too much data being sent too quickly or so...