TCP Server crashing

Monkey Forums/Monkey Programming/TCP Server crashing

Kaltern(Posted 2014) [#1]
Hi folks. I have what seems to be a working TCP server for my needs, however every time the client disconnects, it causes the server to crash with no error. Could someone take a look and see what might be causing it?



At present this server can accept multiple connections, but is not yet designed to actually service them all.


nikoniko(Posted 2014) [#2]
Tested your (a bit modificated) code - no crashes with 2 clients (telnet) on GLFW target (WinXP).


Kaltern(Posted 2014) [#3]
hmm this is very odd. I tried using a packet sender and had no crashing either, so I can only surmise it's something to do with the game client code. Any idea what could possibly cause the server to crash - unhandled data packets perhaps?


Kaltern(Posted 2014) [#4]
This is the relevant client code:




nikoniko(Posted 2014) [#5]
No idea, I got a freezing only sometimes.
Try to logging your data before crashes.


Kaltern(Posted 2014) [#6]
There is nothing showing that explains it, but I have discovered that if I make one single connection within my game client, and then close it after send/receiving one single packet, and then ExitApp, that DOES seem to work.

If I close a socket, does this actually release that socket or is it just closed in a virtual sense?


Kaltern(Posted 2014) [#7]
I just did a debug trace when closed the client, and the server is crashing in app.monkey, on Method UpdateGame, _app.OnUpdate.

Only thing in my server in OnUpdate is UpdateAsyncEvents.


Kaltern(Posted 2014) [#8]
And VS Debugger seems to be showing this as the main error:

Unhandled exception at 0x770223A1 (ntdll.dll) in MonkeyGame.exe: 0xC0000005: Access violation reading location 0x00000000.


nikoniko(Posted 2014) [#9]
It means server tries to operate with not existing socket (if exclude system failure). Check your server/client logic again.
Do you turn off auto suspend for server and client?
#MOJO_AUTO_SUSPEND_ENABLED=False


Kaltern(Posted 2014) [#10]
Yes, I turn that off for both server and client.

That kinda makes sense - I'm probably going to rewrite the server using UDP as I think it might serve my needs better, and will probably avoid this sort of issue.

Thanks for the help :D


nikoniko(Posted 2014) [#11]
Kaltern wrote:
I'm probably going to rewrite the server using UDP


UDP is one way protocol so you need make a server and client parts in the server and in the client for two way communication.

Ops. it's not correct, of course.


Soap(Posted 2014) [#12]
What's your OS and firewall setup? Win 7 firewall can cause crashy behavior in some software on occasion.


nikoniko(Posted 2014) [#13]
try to call socket.close() in the OnClose() method on the client side.


Kaltern(Posted 2014) [#14]
Yeah tried that, no change at all. I've switched to a UDP server, using Mark's basecode again, and that seems to be working fine. I assume there won't be an issue with multiple client addresses using his code?

While I understand the one way thing, I have it running without needing to set up a server on the client side - that is, I can send/receive messages without any issues...

Oh, using Win 8.1 with Bitdefender firewall (turned on and off) - no change with the TCP code - I'm pretty sure it's my fault - like I said, UDP is working with no crashes so far.


nikoniko(Posted 2014) [#15]
Monkey's socket implementation (GLFW/IOS/C++) has no code for fix this issue. Monkey application doesn't process FIN/RST answer (client socket destroyed) from a remote host.


Reaper(Posted 2014) [#16]
Havent yet tried to chase this bug down, exact same issue in the code I am using on TCP for multiplayer client-server game.

As far as I can see its simply that UpdateAsyncEvents is still trying to send information to the closed socket, so if I went to a stage of the game ie the main menu where it wasnt
sending much info then exited the clients 1st (in the OnClose I was closing the socket) it would close fine 90% of the time with no crashes.

From this Im assuming its simply a matter of timing, so when the client needs to close if it 1st sends some bytes of info to the server to say its logging off, then have the server send
a logoff acknowledgement and cease transmitting any info before the socket is closed.

As said I havent yet tried to implement this but Im sure this is the cause of the crashes