An existing connection was forcibly closed by the remote host

[TheCodeTraveller]

Hi All,

Anyone seen this message pop up server side? Can't pin point the cause because this is as much info as I'm given. I've checked all of ArenMook's EndReceives and they're all wrapped with exception handlers. This crash is definitely something a client (which I am not yet sure) is sending back to server for processing.

Any tips appreciated on how to debug this (Mac OSX, Unity Mono).

1. Unhandled Exception: System.Net.Sockets.SocketException: An existing connection
2. was forcibly closed by the remote host
3.    at System.Net.Sockets.Socket.DoBeginReceiveFrom(Byte[] buffer, Int32 offset,
4. Int32 size, SocketFlags socketFlags, EndPoint endPointSnapshot, SocketAddress so
5. cketAddress, OverlappedAsyncResult asyncResult)
6.    at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[] buffer, Int32 offset, In
7. t32 size, SocketFlags socketFlags, EndPoint& remoteEP, AsyncCallback callback, O
8. bject state)
9.    at TNet.UdpProtocol.OnReceive(IAsyncResult result)
10.    at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
11.    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C
12. ontextCallback callback, Object state)
13.    at System.Net.ContextAwareResult.Complete(IntPtr userToken)
14.    at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr u
15. serToken)
16.    at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32
17.  errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
18.    at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
19. errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

[ArenMook]

Forced connection close is not an error, but a warning that comes in the form of an exception (which is exactly as retarded as it sounds). By the looks of it it seems to happen when you're receiving data... but for some reason it happens outside the callbacks? As you've mentioned, both BeginReceive and EndReceive are wrapped in try/catch blocks specifically to avoid such issues, but of course I can't guard against something that happens outside my code -- which in this case seems to be the case. Perhaps it's related to the mono implementation on your version of OSX? Or is it happening within Unity? If so, which version?

[TheCodeTraveller]

Hi there,

Thank you for your response and willingness to get involved. Unfortunately still haven't isolated it but thankful you mention outside of your code. I have modified a lot server side in terms of packet handlers, do you think a possible null / nan creeping into a reader, then being serialized out could be the root cause of this? Should be fairly trivial to protect against it my side if this is the case (thought I had already, but just maybe I missed something.)

For what it's worth, server runs stand alone on an x64 vm, client built with unity 4.2.2 under OSX Mavericks. The changes in Mavericks from a networking point of view (socket handling etc.) haven't been changed to my knowledge (thankfully one less thing to worry about).

I do agree with you though, why M$ decided on a hard exception like this for what in essence should be a warning is beyond me. Well at least I know I need to fix something! Would be nice if there was a trace

[TheCodeTraveller]

Here's a thought, I'm testing locally, two Mac OSX instances and one windows instance (game) - I run the server within another VM, same machine. Needless to say the box is being pushed

That's said, if the three clients are set to update at a rate of 20 packets/s - wouldn't I flood my sockets locally? Perhaps this is the hard crash client side, how it's crashing the server I am not sure.

EDIT: wasn't this, set to 4 on each client, still crashed. Digging deeper... day two chasing this issue now.

[TheCodeTraveller]

Line 455 of TNTcpProtocol

1. Buffer next = (mOut.Count == 0) ? null : mOut.Peek();
2. if (next != null)
3.  

After this there is a reference to mSocket. It's possibly wise to check if that socket is still usable at that point. The crash above, is protected against on line 435 but after this there is no try catch around the following send.

[ArenMook]

Thanks for investigating, I will add in this fix. So just to confirm this was the issue?

[TheCodeTraveller]

Hi Aren,

This is possibly one of many, haven't found the root of what triggered the crash in the first place but any protection server side to prevent the entire server going down is good. Just check the relevance of continuing after that, perhaps you intended a hard crash.

Cheers

[gg67]

Has there been any fixes for this? I have a single user who is running into this error when trying to connect to my server (which everybody else can connect to perfectly fine). He was able to make it into the server once by repeatedly spamming the connect button...but I don't know how to make sense of this.

[ArenMook]

There is something in the Pro version, but this post is from a while back, so I honestly don't remember. I suspect you will check in a minute...