User is already logged in Zone

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

ilcygnet
Posts: 8
Joined: 09 Sep 2009, 06:40
Location: Seoul, Korea

User is already logged in Zone

Postby ilcygnet » 21 Feb 2011, 09:55

hi, i need help to resolve login problem.
my problem is like this: for example i logged in as a user using iphone simulator, and disconnect it by terminating simulator after logging in successfully.
then i cannot login again using same username and password - means same credentials.
i think this is about ghost connections so i tried to fix it up using custom login extension which checks session's USER_NAME already exists -- it doesn't work.
and i found no one is online when monitoring in sfs admin tool. what's this?
in short, 1) there is no one connected as a user in the zone, 2) i cannot connect to the zone with same credentials at all.
i think there is a limbo-thing in sfs2x. plz help me :(

p.s: i need forceLogin function in sfs2x...
User avatar
Bax
Site Admin
Posts: 4612
Joined: 29 Mar 2005, 09:50
Location: Italy
Contact:

Postby Bax » 03 Mar 2011, 13:39

Ghost connections are the result of an incomplete socket disconnection which is not acknowledged by the server and can result in a few different problems: re-connecting users be refused because the server thinks that they are still online, the other players in the room will still see the disconnected user online etc...

In reality these pending connections are not fully closed, the TCP stack is still holding them and it's likely that several minutes will pass before the TCP timeout is fired and the connections are finally closed. When this happens the JVM is informed and finally SmartFoxServer can remove the owners of those connections.

The causes behind these "bad disconnections" can be multiple: an abrupt internet disconnection, the network cable being pulled, a crash in the browser or Flash plugin, a disconnection happening from a very slow and problematic connection, etc...

Since this problem is not avoidable SmartFoxServer provides several tools to deal with it:

- User max idle time in Server Configurator module of the Admin Tool: allows you to specify the maximum amount a client can stay idle (not sending any requests) before being auto-disconnected. The server continuously monitors the connected user activity and attempts to kick the idle ones, including ghost-connections.

- Session max idle time in Server Configurator module of the Admin Tool: this is similar to the previous one but it controls only those socket connections that haven't performed any login yet. This is useful for getting rid of idle connections coming from bots or any other "automated spiders" that scans the web for attackable services.

- Disconnect ghost user on login: create a server-side custom login handler as described in this document and in the the login handler check if the user already exists, for example like this:

Code: Select all

public class LoginEventHandler extends BaseServerEventHandler
{
   @Override
   public void handleServerEvent(ISFSEvent event) throws SFSException
   {
      String name = (String) event.getParameter(SFSEventParam.LOGIN_NAME);
      
      User user = getApi().getUserByName(name);
      
      if (user != null)
      {
         trace("USER ALREADY EXISTING --> DISCONNECTING");
         getApi().disconnectUser(user);
      }
   }
}
Paolo Bax
The SmartFoxServer Team
jamesr
Posts: 104
Joined: 14 Oct 2010, 14:56

Postby jamesr » 14 Mar 2011, 16:48

i want to pass a more specific message than 'unknown' to the user who is discconected. But if i try to pass a second param to the method to specify why the user has been disconnected, the first user gets disconnected as expected, but the second user gets refused entry, as a user with their username already exists?

Code: Select all

getApi().disconnectUser(user, ClientDisconnectionReason.KICK );
Last edited by jamesr on 14 Mar 2011, 17:47, edited 3 times in total.
christian.kelvin10
Posts: 1
Joined: 14 Mar 2011, 16:31

Postby christian.kelvin10 » 14 Mar 2011, 17:00

To do this will not work? Or a user-connection refused. I followed the steps in this post and linking to documents on a user logon name refused-but neither work. Becomes the hand shake and then sits there until eventually the connection is interrupted by the user.
jamesr
Posts: 104
Joined: 14 Oct 2010, 14:56

Postby jamesr » 14 Mar 2011, 18:08

On further testing i've found that if you supply a second param to getApi().disconnectUser(), you get different results depending on the value supplied.


ClientDisconnectionReason.UNKNOWN

- this behaves as if getApi().disconnectUser() has not been called. The first user stays connected and the second gets refused access as there's alraedy a user with their username


ClientDisconnectionReason.KICK
ClientDisconnectionReason.BAN
ClientDisconnectionReason.IDLE

- the first user gets disconnected and the second user gets denied access, as there's already a user with their username
User avatar
adenault
Posts: 42
Joined: 07 Feb 2011, 14:22

Postby adenault » 14 Mar 2011, 20:53

At the same time, I've noticed that some of these ghost connections remain on the server, event if the idle timeout has passed. I've seen a ghost connection stay up to 30 minutes until I got tired and rebooted the server.

Can anyone confirm having similar behavior?

It's pretty hard to produce, and only happens about every 5000 connections.

Cheers,

Alex
User avatar
Lapo
Site Admin
Posts: 23027
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 15 Mar 2011, 11:23

Yes, the ghost connection is "ghost" for one main reason. The underlying TCP socket remains in a non-closed state. Typically it is the CLOSE_WAIT state. What does this mean?

Closing a socket requires a 4-way message exchange between client and server. When the client goes bananas (the infamous IE + Flash Player socket problem, among others) it doesn't perform the full CLOSE operation leaving the socket in a semi-open state. (CLOSE_WAIT means ... server waiting for client to finish the CLOSE operation)

Since the CLOSE operation never get to a full completion the socket remains pending at the OS level for an undefined amount of time. Typically each OS has its own TCP timeouts that get fired after a while, usually it's at least in the range of several hours...

Until this mechanism goes off, SFS has absolutely no way to either detect or get rid of any of these pending connections.
The only way to get rid of them is to use a very low level approach. If you have a configurable firewall it is very likely that you can correct the problem. Firewalls can eliminate this issue because they work at the TCP level, side by side with the OS

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
User avatar
Bax
Site Admin
Posts: 4612
Joined: 29 Mar 2005, 09:50
Location: Italy
Contact:

Postby Bax » 15 Mar 2011, 15:08

jamesr wrote:On further testing i've found that if you supply a second param to getApi().disconnectUser(), you get different results depending on the value supplied.


ClientDisconnectionReason.UNKNOWN

- this behaves as if getApi().disconnectUser() has not been called. The first user stays connected and the second gets refused access as there's alraedy a user with their username


ClientDisconnectionReason.KICK
ClientDisconnectionReason.BAN
ClientDisconnectionReason.IDLE

- the first user gets disconnected and the second user gets denied access, as there's already a user with their username

You can't specify a disconnection reason. This can be done by the server only (and automatically).
Paolo Bax
The SmartFoxServer Team
jamesr
Posts: 104
Joined: 14 Oct 2010, 14:56

Postby jamesr » 21 Mar 2011, 11:10

Thanks Bax
mente
Posts: 73
Joined: 14 Apr 2011, 14:27

Postby mente » 18 May 2011, 07:32

Hello,
I've got the same problem. User is logged in for more than hour.

Code: Select all

$  netstat -n | fgrep 9933

shows empty results. Probably it's not OS-related problem.
Server version - RC2a.
JVM - java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
OS - latest CentOS 5.5
Any ideas or plans to fix it? Will try to reproduce.
shengyuwei
Posts: 2
Joined: 29 Nov 2011, 08:27

Postby shengyuwei » 29 Nov 2011, 08:44

Hello,
I've got the same problem and i tried this code when the ghost connection appeared.

Code: Select all

public class LoginEventHandler extends BaseServerEventHandler
{
   @Override
   public void handleServerEvent(ISFSEvent event) throws SFSException
   {
      String name = (String) event.getParameter(SFSEventParam.LOGIN_NAME);
       
      User user = getApi().getUserByName(name);
       
      if (user != null)
      {
         trace("USER ALREADY EXISTING --> DISCONNECTING");
         getApi().disconnectUser(user,ClientDisconnectionReason.KICK);
      }
   }
}

But the user not destroyed,the ghost connection is still there
User avatar
Bax
Site Admin
Posts: 4612
Joined: 29 Mar 2005, 09:50
Location: Italy
Contact:

Postby Bax » 29 Nov 2011, 10:39

Do you have a way to reproduce this issue? If not it can be very difficult to understand what is going on.
Paolo Bax
The SmartFoxServer Team
User avatar
copet80
Posts: 42
Joined: 27 Apr 2010, 22:23
Location: Australia
Contact:

Re: User is already logged in Zone

Postby copet80 » 26 Apr 2012, 02:48

Hi, we're also experiencing the same problem with the ghost connection, with the problem appearing intermittently when we have 250 concurrent connections or more.

Has anyone found out how to close the connection, or get around the CLOSE_WAIT problem, or fix it on a lower level?

I can't seem to find a definite solution on the internet as well, one such discussion blames Java for some reason that I could not apprehend:
http://stackoverflow.com/questions/1552 ... t-was-grac

I'd be interested to know if anyone has got a working solution as we're bleeding traffic into our games with this ghost connection.
User avatar
Lapo
Site Admin
Posts: 23027
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: User is already logged in Zone

Postby Lapo » 26 Apr 2012, 08:33

Yes, being Java a portable runtime it doesn't have access to low-level details of the TCP stack.
However ghost connections should be a minor issue, in the range of 1-5% of the overall traffic. If you are getting a lot of them chances are that there are network problems on your hosting side, maybe a firewall or router configuration is causing the connections to close prematurely or to hang in CLOSE_WAIT for too long.

I'd be interested to know if anyone has got a working solution as we're bleeding traffic into our games with this ghost connection.

What does this mean exactly?
Lapo

--

gotoAndPlay()

...addicted to flash games
karfau
Posts: 25
Joined: 02 Sep 2011, 17:28

Re: User is already logged in Zone

Postby karfau » 26 Apr 2012, 15:06

We are experiencing the same problem. and are trying to diagnose it.
We found a solution that works in most cases:(no code, sorry)

do the lookup for the other connection with the same username as described above,
if found, tell the API to disconnect the User.
as this doesn't seem to happen imedeatly, we call Thread.sleep(x) until
Success: the user is disconnected (can't be found by name)
or
Failure: we waited more then the maximum waiting time
if the user could not be disconnected we fail with a specific message

We started this with a max waitingtime of 500ms, but if it works, according to the log, in most cases it takes about 10 to 20ms to disconnect the user.
In the meantime it seems that there are more and more cases, where even with a max. waiting time of 3 seconds the Api is not able to disconnect the users.

So I have two questions:
1) Is there any other way to enforce the disconnection, like changing the username of the user on the old connection or manipulating the sessions in some way to allow the user to get connected?
(How is this solved for the force logout feature?)
Because there are many people that say they are so sure they don't have "another game open". Any thing that could solve this problem would be great.

2) Is there anything in the configurations, that could be tuned that would improve the chance for the API to get the user disconnected? What I mean is: could this beeing a problem with the server being to busy so that the thread that should disconnet the user never is running? How could this be detected when monitoring the Zone in the admin console?

The issue is really big, because it targets about over 10% of the swf-clients that try to connect to the game.

Thx for any info,
karfau

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 115 guests