I have a server/client app using WSAAsyncSelect everything seems to work fine appart from one strange problem, every now and then (seems to be random) one of the clients seems to lose connnection as if a time-out has happend.

This even happens if the server and clients are just sitting not doing anything more than waiting for events to happen.

What could be causing this? can you change the time-out settings when using WSAAsyncSelect? or maybe you have to keep the connection alive...

Any help is much appreciated.

Posted on 2004-08-24 16:47:37 by Lennon
I'm still been trying to find some information on this without much luck, all i need is a pointer in the right direction :?

maybe its a simple case of making the server ping the clients to keep connections alive... Bogdan did you have any problems like this with your HE chat client/server?

Posted on 2004-08-26 19:06:58 by Lennon
in my opinion the ping isnt needed as tcp connection normally stay alive. I wrote several chat programs and network applications myself but never came to something like this bug. Please post code...
Posted on 2004-08-27 07:19:35 by Dom
Well, i actually posted a version of the app on this board a long time ago -: http://www.asmcommunity.net/board/viewtopic.php?t=12977

It is much improved now with loads of extra's like file transfer/away states/sounds/background pictures etc, and at the moment i am working on webcams...

But the underlying winsock code is still the same now as it was then and they both suffer from this same problem of certain people losing their connection every now and then.

I didn't mention that it only happens to certain connections, i have a 4 computer home network and 3 of the computers always stay connected, it is only the computer downstairs that gets disconnected for a few seconds maybe 1-2 times a day.

What happens is the other server/clients don't notice that the other client has disconnected until it re-enters the room, for example we end up with 2 people called "fred" in the room....(my new app actually notices the duplicate now and adds numbers to the end of the second name e.g. "fred,fred123") then after a few seconds the original one "times out" and exits the room.

I'm finding this very hard to explain as you have probably noticed :P

Maybe it is a problem with the network cable downstairs :lol: and all i need is some way of checking for dead connections to stop the ghosts in chat.

Posted on 2004-08-27 09:08:56 by Lennon

From what you described, I going to say it's a client problem. Being that the server detects a second / duplicate connection.

You may need to put some extra checking / logging functions on the client in the mean time to determine the fault. Log some things this like, when it makes a connection ( time of event ), seeing that a dup is what's the problem.

BTW, Did you make sure that the client is clean of viruses & adware??

Regards, P1 8)
Posted on 2004-08-27 09:26:09 by Pone

Well its not a Virus/Spyware problem...

What happens on the client side is the connected client recieves a WM_CLOSE message as it should when it losses connection, it then tries to re-connected to the server... which it does first time.

On the server side, nothing is picked up on the disconnection of the client, it just carries on as normal untill the client re-connects (so we have the ghost client and the newly connected client)

then after a few seconds the server gets the WM_CLOSE message about the ghost client being disconnected and removes it.

What i would really like to do at the moment is program the server to test for dead connections, im just not sure what is the best way to go about it.

Posted on 2004-08-28 10:34:03 by Lennon
Similar prolem to what i had in my chat program:
I suppose your client crashes ~ something like that ~ so the server never gets notification that the connection is crashed or closed.
try the following:
after each recv-call (is in your SocketReceive) check the return value in eax: if it is 0 then call closeconnection + everything you normally call when releasing a client...

I'm not too sure about this although i remember this as a solved problem during my chat-prog...

Posted on 2004-08-30 02:56:06 by Dom
after each recv-call (is in your SocketReceive) check the return value in eax: if it is 0 then call closeconnection + everything you normally call when releasing a client...

The new version of my Network Chat already has that code in place, it doesn't seem to help much :?
Posted on 2004-09-01 11:11:31 by Lennon
okay, i think your wnd message processing isn't complete:

mov eax,lParam
and eax,0ffffh

cmp eax,FD_CLOSE
je Wnd_SocketAccept_FD_CLOSE
cmp eax,FD_READ
je Wnd_SocketAccept_FD_READ

While the loword of lparam holds the FD message (FD_READ...), the hiword of lparam defines if there was an error.
For example there are cases where connecting a socket failed but an FD_CONNECT msg comes in - with error in hiword of lparam...
i'm not sure but try to check this for the FD_READ msg...you might receive an FD_READ msg with error information when the connection gets shut down...

Hope I could help,
Posted on 2004-09-02 00:24:32 by Dom
Regardless, it might be time to begin looking at alternative socket models, because the WSAAsyncSelect variant of nonblocking sockets has problems. Sure, it's fine for one or two clients at low bandwidth, but when you push your client hard, it will fall over. One of the reasons for this is the sheer amount of WindowMessages generated by the system to alert you to socket events.. you will find that first your MessageQueue becomes jammed (freezing your GUI), and then the socket layer shits itself because it runs out of buffer space (WSAENOBUFS etc).
That being said, you should think of this model as a "beginners" socket model, and perhaps look at an event-triggered model (my suggestion is using WSAEventSelect at least on the client side, and if you feel adventurous enough, IOCP on the server side (and I understand it IS possible to use IOCP clientside also).
The longer you choose to stay with this socket model, the more you will prefer you had not.
Posted on 2004-09-07 00:49:13 by Homer

Thank you very much for the help dom, as far as i know FD_READ doesn't return error codes in the hi-word of lparam, only FD_CONNECT & FD_CLOSE do, and im handling these as needed.

It looks like the problem is a faulty network cable used by this client as everything works fine when connecting to other clients on LAN/WAN

Of course if a client is "cut off" it has no way of communicating this to the server. Im just not sure IF (we probably have to do it ourselves) or what tests winsock uses to test for a dead connection, thats why i asked if there was some kind of time out system.

Your totally right EvilHomer2k, i starting making this thing to learn Winsock and so chose something nice and simple, its worked out well and i have enjoyed it....but now i'm dying to move onto something more powerfull...

Posted on 2004-09-07 11:35:30 by Lennon