[RESOLVED] [Winsock] When Client "Ends Process" winsock control does not close

Hi there, I have searched forums to no avail...

I have a Server/Client program to send and receive messages,

Very simply:

• The Client connects to the server fine and can receive and send messages
• If the client form is closed, the server correctly Closes the winsock control

However if the Client opens up Processes from Ctrl+Alt+Del and "Ends Process" on the Client Form, the winsock_Close event DOES NOT get triggered on the Server, therefore still thinking there is a valid connection.

I assumed that even if the Client form was closed even with End Process that the server would call the winsock_Close event as the connection was closed.


No real reason to post any of my code, however just so you are aware, on the server application this is the code that closes the connection:

Code:

---

Private Sub winsock_Close(Index As Integer)
    winsock(Index).Close  'close connection
    Unload winsock(Index)
End Sub

---

Thanks for taking the time to read this, please post any ideas?

Take a look at Dilettante's consise and complete explanation in Post #4, here: http://www.vbforums.com/showthread.php?t=645712 regarding TCP Disconnection.

hi, thanks for linking that post. thread resolved i guess

Your client should have cleanup code in Form_Unload that does a Close on its Winsock control before completing. End Process in Task Manager first sends the equivalent of clicking the Close widget ("Red X") to your program, watches the process for a bit, then kills the process if it doesn't terminate right away.

As long as you have the Winsock.Close in Form_Unload and your program is properly responsive to window messages then End Process ought to be working as you were expecting.

Calling the Close method in the client should close the client's TCP stream to the server, which signals the server with a Close event. The server can actually keep sending more data to the client over its TCP stream before calling Close itself, though for most applications the server would just stop sendihng and Close right away.

There is a difference between "End Task" and "End Process" buttons in Task Manager.
The first one (under Applications tab) does exactly what you said: It "asks politely" the application to terminate and, if it doesn't, it shows a message that the application is not responding...
The second one (under Processes tab) terminates the application forcefully (and usually immediately).

The same happens when the computer shuts down unexpectedly or the network connection is suddenly lost: Neither Close nor Error events fire.

Well that's true enough as far as it goes.

In the "abrupt terminate" case the server should see error 10053: Connection is aborted due to timeout or other failure. At least that's what I get when I test it.

Quote:

---

Originally Posted by Cube8

The same happens when the computer shuts down unexpectedly or the network connection is suddenly lost: Neither Close nor Error events fire.

---

This is an entirely different situation since the client computer has no chance to clean up the socket if it outright dies. If the network connection is lost you're back to the linked thread above where we discussed these cases. The TCP protocol isn't supposed to give a signal on momentary interruptions.

Hi,
I am developing an internet cafe software and this "RE:" is the only problem left on the program, when client ends process or restart the client computer prematurely, server doesn't trigger winsock_close() so the events on that winsock_close() doesn't execute. is there anyway to fix this?

Place code in the error event for your winsock control on yoru server. As mentioned above you should get a error 10053 which you can trap and clean up your server side connection. You must have code in this event in order to see the error when it occurrs.

Also do not revive old threads that have been resolved. Start a new thread when you have a question.

sorry for reviving this thread, didn't notice how old this thread is, pls forgive...
but as you mentioned the "error event on winsock", rushed and tried it and it worked!...
for a newbie coder like me, you really are my Hero...... ^_^

Try this Source Code. Also I let you use it to work into your projects, because that is the most basic form of writing the code. Also everybody uses it, all of the time when working with the Winsock ActiveX Control Object...

Code:

---

Public Sub Form_Unload(Cancel As Integer)
    frmMain.Winsock1.Close
End Sub

---

PS: Most of the time, there isn't a need or requirement for the Winsock control to be in a control array, that is just when working with the multipul sockets or even users that work on the very same computer or even this can be a server or a client based computer, using a server application...

First, the thread is considered resolved and we should let it rest in peace...
Second, the code you provided will not work, since the connection is terminated unexpectedly.

Then try an Error Handler that will handle the error, when the Form is unexpectedly exited. Before the error is then handled in the handler, try the Source Code that I had posted before you try to work out or handle the error. Then that could work, because that is what I am working with right now, at this very point in time...

You must be joking, right? Tell us one way to make an application detect its forced termination from task manager (for instance). Or maybe when a sudden power failure occurs...

-- Well I can't but then there is a way to check for memory crashes, I guess???

#1: Cause of the fact that Microsoft in Windows 95 had the Blue Screen of Death. Which meant that it could detect memory failures such as crashes, and what not.
#2: The failure to continue responding to the operating system.

Need I say more???

Quote:

---

Originally Posted by dilettante

Your client should have cleanup code in Form_Unload that does a Close on its Winsock control before completing. End Process in Task Manager first sends the equivalent of clicking the Close widget ("Red X") to your program, watches the process for a bit, then kills the process if it doesn't terminate right away.

As long as you have the Winsock.Close in Form_Unload and your program is properly responsive to window messages then End Process ought to be working as you were expecting.

Calling the Close method in the client should close the client's TCP stream to the server, which signals the server with a Close event. The server can actually keep sending more data to the client over its TCP stream before calling Close itself, though for most applications the server would just stop sendihng and Close right away.

---

Now I am quoting a clean up process, that does exist in the function of Visual Basic. And that it couldn't be without, cause there are ways to continue an error handler event, just not to bring it out. As there can in no such language be something like a error fixer, that fixes the computer out of an error. However there are such events, that can be able to error check and then display the error and then tell where that error lays inside the internal or even the external forces of the application running either in the background or even in the foreground of the operating system's resources...

Quote:

---

Originally Posted by DataMiser

Also do not revive old threads that have been resolved. Start a new thread when you have a question.

---

I am very sorry, because of doing so I have awaken older ancient spirits like GWBASIC, etc from it's eternal slumber ,, hehe. Just kidding!!

My Head hurts......

This thread has been resolved twice, perhaps we shold just let it RIP......

Yes, but then who is to say that it has been put to bed, already. I can figure out some of the programming aspects of error checking and handling that haven't been covered. I was able to cover alot of DOS 32-Bit programming in an DOS 8-Bit language, which was called: QBASIC v4.5 for DOS and then we covered alot of errors, and ways to handle them in Windows and DOS platforms...

I was able to cover most of these programming aspects in University and then only touch on them in High School!! I am only covering what I have learnt, and then going to teach other people, the very same. However we then moved onto Visual Basic, at the turn of the century. (LOL ,, Just kidding!!)...

Quote:

---

Originally Posted by ThEiMp

-- Well I can't but then there is a way to check for memory crashes, I guess???

#1: Cause of the fact that Microsoft in Windows 95 had the Blue Screen of Death. Which meant that it could detect memory failures such as crashes, and what not.
#2: The failure to continue responding to the operating system.

Need I say more???

---

The only way I can think of to detect such problems is probably by the use of a driver, which is (was?) not our case here.

OCX or DLL to be exact, has to be written to coninside with the EXE file, that is currently running in the background, eg: Dr Watson, for instance and then catch the error logs as they per say fly into the window at break neck speed...