Thanks for the reply.
I will try to explain my design and try to explain why I cant call recv or
send in this case. Whats happening is that I have a seperate thread that has
to send data (to the socket by calling "send" function) *whenever* the data
becomes available, and this thread does nothing else. So naturally I cannot
keep the thread's infinite loop running all the time. So I use
WaitForSingleObject along with a handle created using CreateEvent. The
thread proc is actually a public method of a class that has the infinite
loop. So I have another public method, in the same class lets call it
setMessage(). Let me explain in steps what happens:
1 - something calls setMessage and passes the data to it in its parameter.
2 - setMessage copies this data to some local variable of this class.
3 - setMessage calls the SetEvent
4 - due to SetEvent call, the WaitForSingleObject returns and the next lines
of code takes the copied data and passes it to the "send" socket function.
It then returns and goes again in the waitforsingleobject call and so blocks
again.
Now for client disconnection notifications purposes I need to be informed at
any time when the socket connection breaks so that I can do some gui updates
based on this. But as you have read above, since I'm in a blocking call to
waitforsingleobject, I cant call "send" or recv. Should I have another
thread calling "send" with zero buffer length after equal interval just to
check if this socket connection is going fine or not? This doesnt seems nice
idea to me.
I need suggestion on this design, how could I make it better? How are others
doing it?
Regards,
Ab.
"Mihajlo Cvetanović" <ma*@RnEeMtOsVeEt.co.yu> wrote in message
news:#H*************@TK2MSFTNGP09.phx.gbl...
Abubakar wrote: lets say I have a connected SOCKET s. At some point in time, I want to
know if the "s" is still valid, that it is still connected. Is there any API
that I can give me this information?
And can I register some callback like thing, that would inform me when
"s" disconnection happens? What I usually do is while I call "send" or
"recv", I get the socket_error and through that I know whats the status. But in
this situation actually I cant wait to call send or recv to know that the
socket is still valid or not.
You can call recv with the zero byte buffer. I'd like to point out that
the programmer should keep track of this sort of things, just as much as
with pointers. There's no function that will tell you whether some
pointer points to a valid object, if you deleted the object then the
pointer is invalid. In the case of sockets, if you called closesocket
then the socket handle is invalid.
The major problem is what if a socket is closed and a new one is opened
with the same value. Any type of check will tell you that "s" is valid,
which is not true.
I deal with this by having a struct that holds a socket, validity flag,
and a reference counter. If the flag is false then the socket is not to
be used/referenced anymore, and when ref_cnt drops to zero destroy the
struct and close the socket.