socket event notification

[connie_liyang]

Hi,

I am working on a tcp server VC++ program. It supports two clients, and if any of the client close the connection, I should close the connection on server side. I have one problem, could any one give me some hint?

how to detect network event (tcp client close)?


Thanks in advance.


Connie

[Mathew Joy]

Originally posted by connie_liyang
Hi,

I am working on a tcp server VC++ program. It supports two clients, and if any of the client close the connection, I should close the connection on server side. I have one problem, could any one give me some hint?

how to detect network event (tcp client close)?


Thanks in advance.


Connie

I guess you want to know how to detect if the clients connection are closed, right? You can detect it when you try to do some activity such as send/recv with the socket. In the case of an immediate recv you'll get 0 as the return value. In other cases it will be WSAECONNABORTED (10053) Error, which you'll have to retrive using GetLastError() call.

[defiler_z]

I don't know how you are going to do this server, but i'll suggest you that: you can make your own close command;
receive data with recv() function:
char buf[MAX_SIZE];
recv(/*socket*/, buf, strlen(buf), 0);
and
if(stricmp("close"/*or smth else*/, buf) == 0)
{
//do cleanup
// close the connection
}

Something like that!

I hope that will help you.

[simpleman]

Hi connie_liyang

I am simpleman

Please refer to WSAEnumNetworkEvents() function

Good luck to you ^^

[connie_liyang]

Thanks all of you for your kind advice.

Yes. I would like to detect the tcp client connection close.

I know when I use recv() or send(), I can detect the connection status. And I'd like to find out, if there is anyway, that I can detect the tcp client close the connection as soon as possible.

Is there anything like callback, which detects the events automatically?

I tried WSAEnumNetWorkEvents(), but I have problem with winsock2.h. Can anyone explain how to use WSAEnumNetWorkEvents()? What's the difference between WSAEventSelect() and WSAEnumNetWorkEvents()?


Connie

[connie_fox]

Hello,


Now I know how to receive close event from the tcp client. That is by using WSAWaitForMultipleEvents(EventTotal,EventArray,FALSE,WSA_INFINITE,FALSE);


However, I have another problem. After the tcp client close its application, and I close that socket, I can never receive any event when any tcp client tries to connect to my server.

ret=WSAWaitForMultipleEvents(EventTotal,EventArray,FALSE,WSA_INFINITE,FALSE);

if ((ret!=WSA_WAIT_FAILED) && (ret!=WSA_WAIT_TIMEOUT))
{
Index=ret-WSA_WAIT_EVENT_0;
for (int i=Index;i<EventTotal;i++)
{
Index=WSAWaitForMultipleEvents(1,&EventArray ],TRUE,1000,FALSE);

if ((Index!=WSA_WAIT_FAILED) && (Index!=WSA_WAIT_TIMEOUT))
{
........
}
else if(NetworkEvents.lNetworkEvents==FD_CLOSE)
{
closesocket(client);
}
}
}


Could anyone give me a piece of advice?

Thanks in advance.

connie

[Lee Peart]

I guess you are asking about how to detect that a client application has closed down in an unclean way or maybe that the network has failed so that data cannot be transmitted between client and server...

When an application closes a socket connection cleanly there are a series of low level (Protocal Layer) messages sent between the client and server processes. When one of the applications (client or server) dies or is disconnected in some nasty way these messages never get sent leaving the other end hanging. The only way to detect this type of failure in a reasonably quick timeframe is to try sending data across the socket. Trying to recv data might not detect the failure.

Because of this, many client server applications will use a simple 'poll' or 'heart-beat' message to verify the connection state. Basically, each process will set a timer after any data is transmitted so that after a reasonable period of time (say 10 seconds), if there has been no further communication from the other side, a small data message is sent to check the other end is still alive. When a poll message is received there should be some kind of poll-reply sent back. This proves to both ends that the line is still open.

A typical way to implement this would be to say that the server will try to poll a client up to 3 times before giving up on the connection. The client will have a slightly longer poll timer so that you don't get both sides trying to poll at the same time. If data is received from the other side before the poll timer expires then the timer is reset without the need to send a poll.

I hope all that makes sense but please ask if there is anything you're unsure about.


Cheers,
Lee

[Mathew Joy]

If you are talking about detecting a client going away without telling, like in the case of power-off or unplugged cable, you have to do the way Lee said. However TCP do have a keep-alive message implemented. The current ( and recommended ) implementation is 2 hrs (in windows). This can be tweaked using registry. But tweaking changes the behavior of all the programs using TCP. Hence it is only advised for experts. However if you are using win 2000, Winsock 2 provides you with a WSAIoctl command SIO_KEEPALIVE_VALS to send the TCP keep-alive message on a per socket basis.

Hope that helps.

[connie_fox]

Hello,

Thanks Lee Peart and Mathew Joy for your kind help.

Do you mean that the reason why my tcp server can not connect to client any more is because the previous tcp client did not close cleanly?

Actually, I am testing with a simple tcp client in VB.

I did the test in the following sequence:
1. start tcp server in VC++
2. start tcp client in VB
3. tcp client connect to server and send data to server (successful)
4. close tcp client application(winsock.close), while tcp server keeps running
5. start tcp client again
6. tcp client connect to server and send data to server (fail with a message "wrong protocol or connection state for the requested transaction or request"). tcp server can not detect the connection from tcp client this time.


I do not know which part has problem, tcp client or tcp server?



Best regards,
connie

[Mathew Joy]

I guess it is the problem with the client. But your statements are confusing. Above you say problem with server connecting to the client and below you say client connecting to the server. Then again you say about sending data. Are you sending data without being connected?

If the client is connecting to the server, then I suggest you to first test with a simple tcp client using basic simple api’s. Finding the problem will be much easier this way. If the parameter for listen() in the server side is greater than 1 then any second connection attempt to this port should be successful. For second attempt are you using the same socket or are you creating a different socket? Also you should remember that you shouldn’t bind the client socket. If you do, you’ll have problems connecting the second time.

[Mindseye]

I too am having some problem similar to this. I am using CAsyncSocket (derived) class as my client. I am creating the socket, connecting to server and use this for all the later communicaions. Like...

//in function CHubSocket::Create()
CAsyncSocket::Create();
//in function CHubSocket::Create()

//in function CHubSocket::Connect()
CAsyncSocket::Connect();
//in function CHubSocket::Connect()

In Mathew's post I noticed 'bind' will make socket to behave different for successive connections, but CAsyncSocket::Connect(); will internally binds I belive, correct me if I am wrong. So any suggestions for a remedy???

Priyesh.