Guarav if your code has no errors we would expect this to work flawlessly at least in your dev environment.
Can you please confirm that even in your dev machine this isn't work at all? Never?
If you check any other examples we provide that use a server extension they all work out of the box. There must be something going in your code.
Server Out of Synch
Hi
I have a similar problem - when the user unplug his network cable - the event is not fired right away. The event will be fired eventually - usually from 30 sec to 5 min in some cases. I've tried the different settings in the config files - userIdletime etc. but they had no effect.
The solution I used in sfs 1.6 is to constantly ping the server. Every user ping the server at 5 sec interval - then you save each user last ping time in hashMap. Also you should start a new thread that every 3 second loop all users in the hashMap and check if there are more than 5 secs from the last ping. If there are more than 5 sec - you forcibly disconnect the user.
I'm searching for a more elegant solution though.
I have a similar problem - when the user unplug his network cable - the event is not fired right away. The event will be fired eventually - usually from 30 sec to 5 min in some cases. I've tried the different settings in the config files - userIdletime etc. but they had no effect.
The solution I used in sfs 1.6 is to constantly ping the server. Every user ping the server at 5 sec interval - then you save each user last ping time in hashMap. Also you should start a new thread that every 3 second loop all users in the hashMap and check if there are more than 5 secs from the last ping. If there are more than 5 sec - you forcibly disconnect the user.
I'm searching for a more elegant solution though.
HiLapo wrote:Guarav if your code has no errors we would expect this to work flawlessly at least in your dev environment.
Can you please confirm that even in your dev machine this isn't work at all? Never?
If you check any other examples we provide that use a server extension they all work out of the box. There must be something going in your code.
You can not reproduce this problem on a localhost machine. The client ant the server should be on a different computers.
Alex
http://forums.smartfoxserver.com/viewto ... 7716#17716
It will never be and there is a good reason for this.I have a similar problem - when the user unplug his network cable - the event is not fired right away.
http://forums.smartfoxserver.com/viewto ... 7716#17716
By test environment I mean a local network (LAN), not the localhost.Hi
You can not reproduce this problem on a localhost machine. The client ant the server should be on a different computers.
Hello Lapo
I am encountering this issue many time. I have already done the way alex is doing. But for this I have to start a thread which may consume server JVM memory. I just want a way that if any user unplug or his network connection breaks the server will be notified about by any of the internalEvent being fired. Is there any way to do that??
I am encountering this issue many time. I have already done the way alex is doing. But for this I have to start a thread which may consume server JVM memory. I just want a way that if any user unplug or his network connection breaks the server will be notified about by any of the internalEvent being fired. Is there any way to do that??
Starting a new thread is not that heavy 
The server will be notified eventually but this really depends on the OS implementation (TCP stack) and it's non-deterministic. In other words it might take longer than you expect.
Unplugging the network cable is not the same thing as a sudden connection close. Any of these scenarios is different and requires a bit more understanding of how the network works to see why there can be cases in which the event doesn't fire immediately.I just want a way that if any user unplug or his network connection breaks the server will be notified about by any of the internalEvent being fired. Is there any way to do that??
The server will be notified eventually but this really depends on the OS implementation (TCP stack) and it's non-deterministic. In other words it might take longer than you expect.
