smartfoxserver.com

We just released an important update of the C# API.
It fixes several issues discussed in the forum recently, improving the threads and memory management.
Updating is strongly recommended.
You can get the new version and read the release notes here: http://www.smartfoxserver.com/download/sfs2x#p=updates

We have found bug in new version:
1. Connect to server from client.
2. Destroy internet connection, client fired OnConnectionLost event.
3. Try to reconnect to server.
4. SmartFox.dll fired exception:

Object reference not set to an instance of an object
at Sfs2X.Bitswarm.BitSwarmClient.Connect (System.String ip, Int32 port) [0x00000] in <filename unknown>:0 //SmartFox.dll
at Sfs2X.SmartFox.Connect (System.String host, Int32 port) [0x00000] in <filename unknown>:0 // SmartFox.dll
at SFSConnector.Connect (.ServerConfigurationHolder server) [0x00000] in <filename unknown>:0 //our client code

Another issue, that is 100% reproducable, bothering us for a year:
1. Connect to sercer from client.
2. Init UDP.
3. Destroy internet connection, client fired OnConnectionLost event.
4. Try to close client. Client will hang out.

This issue presents only if UDP is initialized.

Hi,
thanks for reporting.

Are you recreating the SmartFox object once the client gets disconnected. This is the one and only way to start a new connection.

1. Connect to sercer from client.
2. Init UDP.
3. Destroy internet connection, client fired OnConnectionLost event.
4. Try to close client. Client will hang out.

What client are we talking about exactly? The web player? Mobile device? Under which OS?

Thanks

Are you recreating the SmartFox object once the client gets disconnected. This is the one and only way to start a new connection.

No. We did not do it since start of the project (more then one year ago) and everything was fine.
If it is necessary - we will recreate SmartFox object before reconnect.

What client are we talking about exactly? The web player? Mobile device? Under which OS?

PC Standalone, Windows 7, 64 bit.

Yes, a new instance of the SmartFox object is the way to go.
See if it helps with the Windows crash too. That problem might be more difficult to pinpoint and it's likely to be due to problems with Unity release resources than anything else.

If you have a crash report of some sort we could take a look.
Thanks

Thank you, we will try.

We have tried to clean Smartfox object in OnConnectionLost event. Now we can recconnect to server, if we create new Smartfox object. But issue with closing application is actual anyway. If disconnect happened, application hangs when we try to close it. It does not seem to be an Unity bug, because issue presents only if UDP was initialized. It looks like something goes wrong with UDP stuff, when disconnect happens.

The problem you are describing actually sounds like a Unity bug, because a disconnection from socket should in no way crash the application unless there's some memory leak or bad pointers, behind the scenes, the causes the failure. If this is the case there's not much we can do, but let's not be pessimistic.

We will have to check this on our side and see if there is a workaround.
I will post an update soon.

Thanks

The problem you are describing actually sounds like a Unity bug, because a disconnection from socket should in no way crash the application unless there's some memory leak or bad pointers, behind the scenes, the causes the failure. If this is the case there's not much we can do, but let's not be pessimistic.

As I understand Unity does not work with sokets itself, am I right?. If all work with sokets are located in Smartfox.dll is it possible that Smartfox does not close correctly some threads, connected with UDP stuff?

We will have to check this on our side and see if there is a workaround.
I will post an update soon.

Thank you.

We'll check and let you know

I have tested the scenario you have reported and I can tell you with good confidence that this is not an SFS related issue.
Unfortunately it depends on the Unity engine more than anything else.

The reason is that exporting an executable for Mac works and behaves as expected with no crashes whatsoever, on the other hands the Windows executable does display the problem you have reported. It freezes after a sudden disconnection. At least it does under Windows XP (sp3) although I wouldn't be surprised to see different outcomes under Windows 7 or 8.

I tested using Unity 3.5.x under MacOSX Lion.
I would suggest to try exporting with the latest Unity Editor (as of today should be v4.1) and see if they have fixed the issue.

Thanks

I would suggest to try exporting with the latest Unity Editor (as of today should be v4.1) and see if they have fixed the issue.

We are using Unity v4.1. The problem is still here.

I have tested the scenario you have reported and I can tell you with good confidence that this is not an SFS related issue.
Unfortunately it depends on the Unity engine more than anything else.

Could you explain, why do you think so? Why this issue presents only when UDP is active?

We will have to do some specific tests under Windows.
The reason why I am saying that it is most likely a Windows issue is because the problem doesn't appear under MacOSX, which is the expected behavior. When a multiplatform SDK such as Unity starts to show contradicting behaviors on different platforms it is typically due to specific issues in the native implementation, where we don't have access.

In any case we'll run some more tests under Windows and see if we can work around the problem, somehow.
If not, we'll file a bug report for the Unity dev team.

I will keep you updated.
Thanks

Thank you!

Any news?