Non-Blocking TCP Freeze [Fixed]

[binary1248]

Internally SFML just calls close() on a socket whether you explicitly call disconnect() or just delete the socket. So in this case there isn't much you can do. Laurent will have to change something in the implementation to make TCP connection shutdowns cleaner. This might be what is causing your problems. There is no way to tell until it is changed because SFML is causing RST packets to be sent by TCP even in legitimate disconnects.

In the mean time you should think of a way to inform both sides that the connection should be shut down without relying on TCP telling you that the connection was closed at the remote end.

And regarding my first question: Why does the server establish a connection to the client as well? There are what looks like 2 simultaneous TCP connections between the 2 hosts in the dump. Both sides connect to the other using their own connection. That is what I don't understand. Wouldn't a single connection suffice?

[Jungletoe]

And regarding my first question: Why does the server establish a connection to the client as well? There are what looks like 2 simultaneous TCP connections between the 2 hosts in the dump. Both sides connect to the other using their own connection. That is what I don't understand. Wouldn't a single connection suffice?

Umm... I didn't connect both sides...

You can take a look at my networking code again. That's all it does.

[binary1248]

Well... according to the dump, 192.168.1.14 sent a SYN from port 50282 to 173.73.23.101 port 41011 first. Then 173.73.23.101 sent a SYN from port 1024 back to 192.168.1.14 port 41011. This means that 2 connections are established between the hosts. If only the server is listening for new connections then either the second connection attempt was made by some other application, or something is misbehaving. You can have a look yourself. It's the first 2 packets in the dump.

[Jungletoe]

Well... according to the dump, 192.168.1.14 sent a SYN from port 50282 to 173.73.23.101 port 41011 first. Then 173.73.23.101 sent a SYN from port 1024 back to 192.168.1.14 port 41011. This means that 2 connections are established between the hosts. If only the server is listening for new connections then either the second connection attempt was made by some other application, or something is misbehaving. You can have a look yourself. It's the first 2 packets in the dump.

I still have no idea what could've connected it... the server never connects and no outside applications use that port.

[binary1248]

If you say you are experiencing data loss issues, you should try to replicate it with a simple test program (<100 lines, try sending random numbers with the same seed at one end and verifying them at the other) that transfers a lot of data. See if you can make it lose something the same way you lose data here.

[Jungletoe]

If you say you are experiencing data loss issues, you should try to replicate it with a simple test program (<100 lines, try sending random numbers with the same seed at one end and verifying them at the other) that transfers a lot of data. See if you can make it lose something the same way you lose data here.

I mean... that'll take a while but I'll try. I don't exactly have time to experiment with this. My fan-base recently grew to 200 people and they expect features every weekend...

One of the dedicated testers just gave me this from Very Sleepy after a crash:

[binary1248]

Sleepy indicates that that is Call stack 1 of 5. SFML uses multiple threads while it is running, even more when you make use of multiple audio objects. Most of them will be sleeping the majority of the time and I highly doubt that a sleeping thread can crash an application by itself. It might look like the audio is causing the application to crash but this is a wrong assumption since the audio thread is merely sleeping at the time of the crash. You need to check the other 4 call stacks as well. If one of them indicates that something bad happened in your own code then the problem is probably located there. If you still want to check whether it is the audio that is crashing the application, you can try to switch audio off by means of a switch and let people test it. If it never crashes with the audio off then the crash might very well be because of the audio.

[Jungletoe]

http://puu.sh/2QjCL.png
http://puu.sh/2QjDD.png
http://puu.sh/2QjDO.png
http://puu.sh/2QjDZ.png

[Jungletoe]

It seems to happen when a lot of high-memory packets are sent at once.

[binary1248]

Judging from the screenshots of Sleepy you provided, you probably didn't link against debug libraries. The callstacks are more or less useless in helping you find the problem because either a) something got really screwed up and the stack got corrupted or b) starting a new thread doesn't reveal anything above the initiation point. The main thread that runs your application and probably also crashes it is missing and that is the important one.

If you say you have dedicated testers, they should be given proper debug versions of the application and it should be run in a proper debug environment corresponding to your build toolchain. Hooking into an application after or during execution is very unreliable, even more so in Windows than on Linux and more often than not you won't end up with much useful information.

Sleepy also wasn't meant to be used as a generic debugging tool. It is a callgraph profiler as can be seen in the screenshots. As such I wouldn't be surprised if it isn't able to fully recover callstacks after an application has crashed.

It seems to happen when a lot of high-memory packets are sent at once.

Unless you can consistently isolate and reproduce this, it is probably just coincidence or just correlated in some indirect way.

[Jungletoe]

Unless you can consistently isolate and reproduce this, it is probably just coincidence or just correlated in some indirect way.

I've confirmed that it has to do with lots of high-memory packets being sent at once.

I guess I can try to replicate it.

[Jungletoe]

Okay, I definitely know it has to do with high memory packets. The client basically stops receiving the packets if a lot are sent at once.

Is there any limit on how much memory the network can hold before it's processed in a recieve()?

[binary1248]

What does the packet capture tell you? Are the packets actually arriving at their destination? Are they even being sent from their source?

[Jungletoe]

The packets are being sent from the server to the client but the client is not responding to them because of some distortion or deletion. The problem is with the underlying network, not my code because people have to wait 5 minutes before they can play again-- after closing the client and restarting. The client is not receiving anything since it simply just stops working.

[binary1248]

Can you show me a packet capture of this happening? From both sides if possible.