Page 2 of 2
Posted: 04 Oct 2010, 06:55
by Lapo
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?
Posted: 04 Oct 2010, 16:20
by Fun Bobby
what´s about your roomList sending. if you send the roomList with all rooms for each new user at login you are running into problems and it could produce the beaviour your descripe.
did not go through the whole threat if i am missing something you mentioned earlier.
Posted: 04 Oct 2010, 16:30
by Lapo
@Fun Bobby: Sorry no, the room list won't create this problem, and it's transmitted once, while here the problem seems to keep up with such low traffic.
Posted: 05 Oct 2010, 11:21
by Kleon
Lapo wrote:Thanks... it's actually a bit difficult to interpret it, do you also have a more detailed view of that day?
Here is it:
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.
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?
Yes, I have such function. It updates some data for all users one time per 2 hours then sends updated data to clients.
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?
Posted: 05 Oct 2010, 16:53
by Lapo
Yes, I have such function. It updates some data for all users one time per 2 hours then sends updated data to clients.
Can you show the snippet of code that does that? If you prefer to do it privately contact us at support --at-- smartfoxserver.com
Posted: 06 Oct 2010, 06:23
by Kleon
The function which is called one time per 2 hours:
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);
}
}
and the function which updates client
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])
}
Posted: 06 Oct 2010, 06:48
by Lapo
You mean it is called once every 2 hours?
Can you explain what it does in short?
Posted: 06 Oct 2010, 07:53
by Kleon
Lapo wrote:You mean it is called once every 2 hours?
Can you explain what it does in short?
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.
Posted: 06 Oct 2010, 07:55
by Kleon
The code I sent restores these features in course of time
It updates server user properties, then send response to client with new properties.
Posted: 13 Oct 2010, 07:01
by Kleon
Hello Lapo,
Does this info helps?
Could you suggest us any tests to find a problem?
Posted: 15 Oct 2010, 06:30
by Lapo
Hi,
no I am sorry. I think this requires a more thorough analysis of your setup to understand what's really going on. You can get in touch with us via email and request to open a ticket for dedicated support.
Hope it helps
Posted: 21 Oct 2010, 13:50
by aop_ar
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!!
Posted: 22 Oct 2010, 05:59
by Lapo
In the smartfox admin, we can that the outgoing dropped message is huge.
One possibility you should check is that your application sends too much data for the average client.
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.
How do you know that server is kicking them out?
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...
