[RESOLVED] Winsock again...

Im very sorry guys but im not still an expert on winsock...:blush:

ok heres my problem, i have manage to build a VB6 server and client app and they run very well, but this problem arise when the client app is being terminated "abnormally" like for example the computer is being power off via the power switch so the client did not exited properly and did not informed the server app that it has to exit, so the server app still stay "connected".

i put a winsock_error sub which closes the winsock, but it doesnt fire when the above situation occurred...

any (code) suggestion on how am i going to monitor that situation???

help please thanks...

ok guys, i figure it out already, i was thingking of adding another
winsock control w/c request for a connection to a client every now and then, if it doenst connect then the server will "know" that the client is "dead".

i still appreciate any comments and suggestions if i am doing the right thing and if there is another way to do it, your help would be very much appreciated...

Hmmm, its a strange problem

If you use TCP its a connection oriented protocol, so if the client quits the app the connection should be automatically broken and the Winsock state of the server should change to Error and raise the Error event

No, you have to enable KeepAlives and set the tuning values in order to get the TCP Reset on an expeditious basis.

See http://tangentsoft.net/wskfaq/newbie.html section 2.13

Also see http://msdn2.microsoft.com/en-us/library/ms740476.aspx

Wow! Setting this "keepAlive Interval" sounds like the most efficient way to deal with "broken winsock connection"...big thanks to dilletante...

but i must admit that at this very moment i am still grasping for help on this,
how can i set this KeepAlive functionality? (Im working on Visual Basic language) Please i still need help for this...thanks...

TCP KeepAlives

Enabling TCP KeepAlives in VB6 isn't obvious, but it isn't too hard. However you might keep in mind that many people think this is "evil" for a number of reasons.

Setting that aside however, there are still some problems. On Windows 95/98/Me and NT 4.0 there is no way for a program to set the timing intervals related to TCP KeepAlives on a per-connection basis. So this means you get System default values.

The System defaults are such that it can take about 2 hours to detect a broken connection! Of course you can change things in the registry to use shorter intervals.

In Windows 2000 and later a program can set different interval values on a per-connection basis. Sounds good. But in practice you may find that a Windows security fix disabled this capability, once again leaving your program with System default interval settings.

There may be a registry setting to restore this capability but I can't find it right now.


Application KeepAlives

The alternative is to implement application level KeepAlives in your programs. This is what the "TCP Keepalives are evil" people recommend if you need such a feature.


Sample Programs

I'll try to attach 2 examples based on a simple chat client and server I wrote.

One example is called SimpleChatKA and it detects whether it is running on Win2K or later and tries turning on TCP KeepAlives and setting the interval values short... or if running on an earlier OS it just turns on KeepAlives.

I find that it gets the 2 hour times though no matter what I try.

The second example is called SimpleChatAK and it does application KeepAlives.

The KA version is actually less code but it involves a few API calls and a sneaky trick. The AK version is pure VB6 though it is a little more work.

Note that the intervals I used are quite short to demonstrate the point more easily. The AK version's server detects a broken connection within close to 5 seconds. Be aware that with such short intervals the server is doing a lot of checking and is sending extra traffic over the network. If you could get the AK version's intervals set to reasonably short values the server won't be working so hard, but it will still generate as much extra network traffic.


The KeepAlive Story

The basic principle with both versions is as follows:

• Every time client data is received a timer called "time" starts.
• If "time" goes by with no new data received, the KeepAlive logic gets suspicious and sends a KeepAlive request to the client and starts a timer called "interval."
• If "interval" goes by a count called "probes" is decremented and another KeepAlive request is sent (in case the last one just got lost) and the "interval" timer is started again.
• If "probes" goes to zero, the connection is considered "broken."

The difference is with AK the TCP/IP stacks are doing this work, and in KA the applications (server and client) must do this work.

I wrote the AK version to go through all of the steps above. It may be possible to omit the "probes" count in AK and just call the connection broken when one KeepAlive request times out (interval).


To Recap

So the way it works is...

The server notices that "time" (a relatively long time) has gone by without any input so it sends a KeepAlive.

It waits a shorter time ("interval") for a response to the KeepAlive, and it repeats this several times fairly rapidly until it decides to "give up" and call the connection broken.


Whew!

I know this sounds complicated. Maybe when all is said and done you'll decide not to do it.

To test this you'll need two computers: one to run the server and another to run the client. Once the client is connected you should unplug the network cable from the client and watch for the server to "notice" the broken connection.

Good luck.

BULLSEYE!!!:thumb:

Nice, nice, nice, explanation, this is way too much than ive expected...
And thank you very very much dillettante, you've really help me a lot on this...:thumb:

Your samples must be added to codebank...:)

I'm glad it helped.

To my chagrin, I wish now that I'd used TK (TCP KeepAlives) and AK (Application KeepAlives) when I'd named those. Oh well, I hope it isn't too confusing.

I suspect that somebody could clean up the AK version's code a little too, especially in the Timer event handler. And maybe experiment to see whether or not it is worthwhile to try several probes or just one when a connection is found to be inactive. Cutting that second time interval out would make the logic simpler, and I don't think it accomplishes the same thing that repeated probes at the TCP level do.