[2005] Sockets Problem

[Fromethius]

Hey everyone. I'm making a game with Sockets. Everything works well except for when the client abruptly closes the game. By that, I mean, he presses ALT - F4 to shut down the game, presses the X in the top right, or ends the task or process.

When the client does such a thing, this error occurs with the server application:

IOException was unhandled

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

This occurs in this block of code:

// lock ensures that no other threads try to use the stream at the same time.   
lock (client.GetStream())
{
   // Finish asynchronous read into readBuffer and get number of bytes read.
   bytesRead = client.GetStream().EndRead(ar);
}

On this line:

bytesRead = client.GetStream().EndRead(ar);

I've tried sending a disconnect message when the form is closing on the client's side but it does not alleviate the error.

Normally, this wouldn't be such a big problem, but this crashes the server! Such a thing cannot stand. I suppose I could make the game full screen mode, but one can still ALT - F4, end the task or process, or find some other way of closing the game the wrong way. It would be better to just fix the error.

I have been searching on google for a bit now, but I have yet to find any solutions. Hopefully vbforums can be of some help

Thank you

[RobDog888]

Arent you using any error trapping for IOException ?

[Fromethius]

No.

In a previous chat application I made, I was using the same exact code and such an error never befalled me. This one is new.

Why, what kind do you have in mind?

[RobDog888]

Well at least on the server side you will need to trap and handle the exceptions that are relevant. Then from there you can send your message back to the originating client that the other client is disconnected etc.

[Fromethius]

Well, upon putting the entire function in a try/catch block, it does not crash. However, it does not feel like good coding practice.

Oh well. Whatever works, I guess.

[^^vampire^^]

I've recently been working with tcp sockets and a while back came across the same problem. I tackled the problem by checking if the bytesRead <= 0.

What happens is when the client has some kind of abnormal disconnect the stream received is zero (as far as i know). To handle the problem i used this code in the streamReceived method from my client:

Try
   SyncLock client.GetStream 'so no other threads try to access at same time
      BytesRead = client.GetStream.EndRead(ar)
      If (BytesRead <= 0) Then 'Abnormal disconnect from client
         RaiseEvent Disconnected(Me)
      End If
   End SyncLock
Catch e As Exception
   'error
End Try

I also had another block of code that handled the Disconnected() event to remove the username from the UI etc.

I hope this helps

[EDIT]

Something else that might help - when the client disconnects/closes the connection by choice or forcibly, if the client is coded in vb you can try putting the following into the FormClosing event of the main form:

Select Case e.CloseReason
   Case CloseReason.ApplicationExitCall
      'closing procedure
   Case CloseReason.FormOwnerClosing
      'closing procedure
   Case CloseReason.MdiFormClosing
      'closing procedure
   Case CloseReason.None
      'closing procedure
   Case CloseReason.TaskManagerClosing
      'closing procedure
   Case CloseReason.UserClosing
      'closing procedure
   Case CloseReason.WindowsShutDown
      'closing procedure
End Select

You can try selecting which closing reason may apply and then send a text message to the server with a disconnect command.
Both of these methods have seemed quite effective to me.

[Fromethius]

Thanks. These try/catch's actually have some use, after all.

[RobDog888]

Try Catch blocks are error handling and every good app will make use of them as needed. You surely dont want your app to crash all the time because of unhandled errors. It wouldnt look too good or professional.

[Paul M]

Oh and Sockets from SocketExceptions You can also catch normal Exceptions though