forums.smartfoxserver.com

Hi,

We have a SmartFox server and Flex based clients that randomly disconnect from the SmartFox Server. In the SmartFox Server log we just see user [xxx] was removed. the clients start disconnecting a few minutes after they connect to the SFS server.

We are using Flex client API and SFS 1.6.6. WE also tried pinging the SFS every 5 seconds using the roundtrip check to try and keep the tcp connection open.

Config file is standard with minimal changes, we got the same behavior on a Linux installation and a Windows one.

Please advise

Thanks
Shai

shaih wrote:Hi,

We have a SmartFox server and Flex based clients that randomly disconnect from the SmartFox Server. In the SmartFox Server log we just see user [xxx] was removed. the clients start disconnecting a few minutes after they connect to the SFS server.

We are using Flex client API and SFS 1.6.6. WE also tried pinging the SFS every 5 seconds using the roundtrip check to try and keep the tcp connection open.

Config file is standard with minimal changes, we got the same behavior on a Linux installation and a Windows one.

Please advise

Thanks
Shai

Have you tried downloading 1.6.8?

I still need to apply 1.6.9 to flash client side, but updating the server only did not solve the problem.

What is the best way to keep the TCP connection open, are there any recommendations?

Thanks

What is the 'actual' message (related to users getting removed) you're seeing in your SmartFoxServer log?

The message I get is:

User [ USER_NAME] removed

We also ran test as follows:
Setting the idle time out to 60 seconds
connect with a client that will send a message to himself every 30 seconds

We assumed the message will start calculating the idle timeout with each message (since the user was not idle anymore)

But the SFS still disconnects the user.

Can you please help

Thanks
Shai

Which idle time are you setting?

There are two different types of idle times:

MaxUserIdleTime (this is for users who are logged in)
MaxSocketIdleTime (this is for users who aren't logged in)

both set for 1 hour, 3600 seconds

Hello,


In the java we do it like mentioned below
To make the connection opened we send the message from client to server and server execute the above code and make the connection alive..
Hope it helps..

shaih wrote:We are using Flex client API and SFS 1.6.6. WE also tried pinging the SFS every 5 seconds using the roundtrip check to try and keep the tcp connection open.

The issue is right here, roundtrip check message doesn't restart the timer, you need to keep the connection alive using some other type of messages for example using extension or public message.

We also tried sending a message to self every x seconds, this seemed to have the same effect on the idle time out. We have made a test where we changed the idle timeout to 2 min and sent a message to self every 30 seconds. After 2 minutes the user was thrown from SFS.

Another one we saw was that some times SFS just kicks some users and we couldn't find the reason (might be network issues) but it happened in our internal LAN and in another environment as well.

Is there a way to find out why the socket disconnected? any logs or any suggestions would be appreciated (SFS logs are set to FINEST, no reason in the log for the disconnection)

Thanks

I just tried simple client which sends constant string private message to myself in a minute interval while the idle timeout is set to 5 minutes. And it does work quite well when i checked i was still online after an hour.

As far as i know there is no way you can detect what was the issue for a particular user disconnection. Just look for other clues such as # of dropped messages which are the most common.

A few quick tips:
1) The best way to keep a connection alive is to ping the server every 30-60 seconds sending an empty
2) (Optional) It is a very good a idea to keep the <MaxIdleSocketTime> to a low value, ideally < 60 seconds.

If you keep seeing the problem then you should look somewhere else for the cause. It could be a client connection problem or a generic network problem.
We have also seen a few rare cases in which it was the hosting provider itself having network stability issues.