We're very close to release and testing a feature that lets players reconnect in real-time if one of the players disconnects in the middle of a match.
The player who disconnects doesn't seem to be firing an onDisconnection event if that player has a Mac laptop and disconnects by turning off the wireless. Of course, the other player seems to get a notice just fine (even if that player is on a Mac with a wireless connection), presumably because the notice came before he/she got disconnected. The issue is only with the player who disconnects, so this seems to be a bug of some sort related to either the SmartFox onDisconnection event in the client API, or maybe Flash?
Has anyone else had this problem?
Client onConnectionLost not being detected in OS X
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
Client onConnectionLost not being detected in OS X
Last edited by torncanvas on 20 Dec 2008, 16:27, edited 2 times in total.
Hello,
I mostly use MacOS X and never experienced such problem.
Is this happening on one Mac laptop? Or do you test on multiple Macs?
It might be a problem with a specific machine or it could be a combination of OS settings + Browser
Anyways in order to investigate more we'd need to know:
OS version
Browser name/version
Flash Player version
I mostly use MacOS X and never experienced such problem.
Is this happening on one Mac laptop? Or do you test on multiple Macs?
It might be a problem with a specific machine or it could be a combination of OS settings + Browser
Anyways in order to investigate more we'd need to know:
OS version
Browser name/version
Flash Player version
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
We've tested this problem on a Rev A Macbook Pro and the new Macbook Pro model that just came out with dual graphics cards and the trackpad button, and then a Macbook Pro model that's roughly in between those two.
The Rev A runs OS X 10.4.11 and the two newer Macbook Pro models run the newest version of 10.5. We've used FF3, although we can test with Safari later today. Two of them have the latest Flash 10 Debug, and I can check on the third. We might be able to test with the Release version later today as well.
I don't believe this is a problem with our code, since it can't be reproduced on a Windows machine, though it would be prudent of us to test that with several different Windows machines.
The Rev A runs OS X 10.4.11 and the two newer Macbook Pro models run the newest version of 10.5. We've used FF3, although we can test with Safari later today. Two of them have the latest Flash 10 Debug, and I can check on the third. We might be able to test with the Release version later today as well.
I don't believe this is a problem with our code, since it can't be reproduced on a Windows machine, though it would be prudent of us to test that with several different Windows machines.
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
Yes, I mean onConnectionLost I apologize. You've referred to it as onDisconnection is a previous thread so I thought that's what the name was, but after looking in the docs, I can see it's onConnectionLost.
Unfortunately, I can't easily test the example apps since I don't have an easy way to set up an SFS server to host them. I'd be happy to test someone else's if they have them up somewhere.
The only thing I can confirm is that this happens with Macbook Pro laptops that are connected via wireless, and not with PCs based on our tests. One of our software engineers thinks this is related to the OS X network stack behaving differently, and that not being accounted for.
Unfortunately, I can't easily test the example apps since I don't have an easy way to set up an SFS server to host them. I'd be happy to test someone else's if they have them up somewhere.
The only thing I can confirm is that this happens with Macbook Pro laptops that are connected via wireless, and not with PCs based on our tests. One of our software engineers thinks this is related to the OS X network stack behaving differently, and that not being accounted for.
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
It could definitely be the configurations of the computers themselves. It doesn't seem to be the routers, because we've tested this from several different locations. And we first noticed the issue because we tested a PC and Mac from the same router, so if it was the router than both machines should have the issue. But the PC detected the disconnection, and the Mac didn't.
I'll try some other PCs from the local library, and then my laptop from the same location, and see what happens.
Actually, you know what you could do that would be a big help? Just test our game and see what happens. Head here: http://www.kongregate.com/games/intuiti ... waurs-beta
Jump in tutorial 3, go through the weapon tutorial screens, then disconnect your wireless. What should happen is that as soon as you disconnect, you should get a dialog saying that you're disconnected and that you're waiting to get reconnected. When you enable the connection again, the dialog will go away a few seconds later. That's what happens with the PCs we've tested.
But what happens on the Macs we've tested is that the game will just freeze - you'll be able to move only a little bit and then the dino will slide back, and your gold should stop going up. That means you're disconnected, but an onConnectionLost wasn't fired. Then once you enable the connection again, the game will finally notice that you were disconnected, it'll bring up a dialog saying it's trying to reconnect, then a few seconds later you should be reconnected.
I'll try some other PCs from the local library, and then my laptop from the same location, and see what happens.
Actually, you know what you could do that would be a big help? Just test our game and see what happens. Head here: http://www.kongregate.com/games/intuiti ... waurs-beta
Jump in tutorial 3, go through the weapon tutorial screens, then disconnect your wireless. What should happen is that as soon as you disconnect, you should get a dialog saying that you're disconnected and that you're waiting to get reconnected. When you enable the connection again, the dialog will go away a few seconds later. That's what happens with the PCs we've tested.
But what happens on the Macs we've tested is that the game will just freeze - you'll be able to move only a little bit and then the dino will slide back, and your gold should stop going up. That means you're disconnected, but an onConnectionLost wasn't fired. Then once you enable the connection again, the game will finally notice that you were disconnected, it'll bring up a dialog saying it's trying to reconnect, then a few seconds later you should be reconnected.
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
I'm here at the library and I've just tested the game on a PC with IE7, and then on my laptop with FF3. The PC detected the disconnection, and my Macbook Pro in OS X didn't.
Also, I booted into Windows XP on my own Macbook Pro. In Windows, using FF3, my disconnection was detected immediately. So far this is pretty strong evidence that due do a difference in OS X (10.4.11 or higher), network disconnections are detected differently and our code responds according to that difference.
Anyone have any ideas or theories?
Also, I booted into Windows XP on my own Macbook Pro. In Windows, using FF3, my disconnection was detected immediately. So far this is pretty strong evidence that due do a difference in OS X (10.4.11 or higher), network disconnections are detected differently and our code responds according to that difference.
Anyone have any ideas or theories?
wait a minute... you say "disconnect the wireless" and see what happens...
That's not the way to do it. Unplugging your physical network cable or the wireless can produce all sorts of different behaviors depending on your OS, browsers and other 300 layers of software
(This kind of operations has already been discussed in this board, you can search for it if you want more details)
When a client experiences a disconnection its not certainly due to its network card going down but simply because one if it's "channels" (socket conection) going down for different reasons (ISP, route of the connections, huge lag, cosmic rays ... you name it )
If you want to test disconnection events on clients simply kick the client from SmartFoxServer and see what happens. You should definitely see the client react to that.
That's not the way to do it. Unplugging your physical network cable or the wireless can produce all sorts of different behaviors depending on your OS, browsers and other 300 layers of software
(This kind of operations has already been discussed in this board, you can search for it if you want more details)
When a client experiences a disconnection its not certainly due to its network card going down but simply because one if it's "channels" (socket conection) going down for different reasons (ISP, route of the connections, huge lag, cosmic rays ... you name it
)If you want to test disconnection events on clients simply kick the client from SmartFoxServer and see what happens. You should definitely see the client react to that.
-
torncanvas
- Posts: 12
- Joined: 23 Apr 2008, 13:28
We are trying to cover cases where users get legitimately disconnected from the internet, so we can try to gracefully reconnect them if the connection comes back shortly after the incident.
I have had some incidents myself where my network connection has legitimately dropped without any action on my part, and in OS X the behavior was such that an onConnectionLost was not fired. That is the core issue we are trying to resolve, and we can recreate that issue by disabling the connection. No matter what happens to the connection, if it stops working, shouldn't an onConnectionLost event be fired? If that isn't the case, then that is exactly the information I am looking for, so that we can provide a workaround to account for the fact that an onConnectionLost event is not fired in all disconnection cases.
In terms of disconnections, I don't think you can say there is a "right" or "wrong" way. Either you stay connected, or you stop being connected at some point. There are real cases where our players using OS X are losing their connections and the event is not being fired. I've had a couple of those myself. We're simply trying to figure out what the issue is in these cases, and come up with a solution based on that knowledge. So far, we've been able to reproduce the behavior by disabling the wireless. Just to be safe, I'll continue to test through other means and let you know how that goes.
I have had some incidents myself where my network connection has legitimately dropped without any action on my part, and in OS X the behavior was such that an onConnectionLost was not fired. That is the core issue we are trying to resolve, and we can recreate that issue by disabling the connection. No matter what happens to the connection, if it stops working, shouldn't an onConnectionLost event be fired? If that isn't the case, then that is exactly the information I am looking for, so that we can provide a workaround to account for the fact that an onConnectionLost event is not fired in all disconnection cases.
In terms of disconnections, I don't think you can say there is a "right" or "wrong" way. Either you stay connected, or you stop being connected at some point. There are real cases where our players using OS X are losing their connections and the event is not being fired. I've had a couple of those myself. We're simply trying to figure out what the issue is in these cases, and come up with a solution based on that knowledge. So far, we've been able to reproduce the behavior by disabling the wireless. Just to be safe, I'll continue to test through other means and let you know how that goes.
As you have mentioned there are many reasons why the connection could go down. There's however one particular case that usually creates more headaches (at least in this field of browser based apps/games) that is when you pull the network cord or shut down the network interface.
When this happens the TCP protocol is unable to send and receive the proper "close" signals over the socket connection. This happens at the OS level so there's not much we can do from both the Flash side or the Java side.
Depending on the OS type and its TCP implementation it will take some time before the TCP stack will realize that the connection(s) have timed out.
On the SmartFoxServer side this does very little harm.
If you connect a client and then pull the cable the server will not notice it and think it's still there, however the user will be removed from the server after the <MaxUserIdleTime> is elapsed.
On the client side you usually get a disconnection message after a few seconds/minutes after the network is reactivated, because the TCP realizes that certain older connections are dead. (Changes from one OS to another)
I hope this clarifies the problem a little bit.
p.s. = on a side note I'd like to point out that this "cable-pulling" thing doesn't happen very frequently so 90% of the times disconnections are acknowledged correctly
When this happens the TCP protocol is unable to send and receive the proper "close" signals over the socket connection. This happens at the OS level so there's not much we can do from both the Flash side or the Java side.
Depending on the OS type and its TCP implementation it will take some time before the TCP stack will realize that the connection(s) have timed out.
On the SmartFoxServer side this does very little harm.
If you connect a client and then pull the cable the server will not notice it and think it's still there, however the user will be removed from the server after the <MaxUserIdleTime> is elapsed.
On the client side you usually get a disconnection message after a few seconds/minutes after the network is reactivated, because the TCP realizes that certain older connections are dead. (Changes from one OS to another)
I hope this clarifies the problem a little bit.
p.s. = on a side note I'd like to point out that this "cable-pulling" thing doesn't happen very frequently so 90% of the times disconnections are acknowledged correctly