how to interrupt WSARecv if connection is lost

[Sergey]

Hi
Server side uses blocking socket and reads data with use of WSARecv
function via network from client .
Client side lost connection (I simply remove connector from network
card), but WSARecv function on server side pending read . How to
force WSARecv to return if connection on client was lost?
Thanks

[Peter Duniho]

As far as the server is concerned, the connection isn't "lost" until it
tries to send data and fails. There's nothing to detect until then.

The literal answer then to your question is that the server needs to try
to send data. You can either enable "keep alive" which has, I think, a
two-hour interval by default, or you can implement some kind of "keep
alive" in your application protocol, wherein your server sends a query
and expects an acknowledgment on some regular basis.

Alternatively, just maintain some kind of connection "timeout" and
discard the client connection if you haven't received anything from the
client after some period of time.

Without knowing the application protocol and what your exact needs are,
it's hard to suggest something more specific. But hopefully those ideas
give you a starting place.

As far as the call to WSARecv() goes, once you've either caused an error
(by trying to send data) or simply closed the connection, that function
should return with an error.

Pete

[David Schwartz]

The connection hasn't been lost. The only thing that has happened is
that if either side were to try to send data, that data would not go
through, something that side could detect. The only way to detect that
is for one side to try to send data.

What protocol are you implementing? Its specification should tell you
how to handle this case, either by specifying some kind of test data
you can send or a timeout or some other mechanism.

If the specification tells you how to handle this case and you didn't
follow the specification, your application is broken. If the
specification doesn't tell you how to handle this case, the
specification is broken. (How to fix it is specific to the protocol,
unfortunately, there's no 'one right way'.)

DS

[Sergey]

> What protocol are you implementing? Its specification should tell you
> how to handle this case, either by specifying some kind of test data
> you can send or a timeout or some other mechanism.
>

I use stream sockets with TCP protocol

[Sergey]

Thanks for all
SO_KEEPALIVE socket option helps for TCP streaming socket
-)

[David Schwartz]

You misunderstand my question. What protocol are you *implementing*?
You are not implementing the TCP protocol as that's already
implemented.

The protocol you are implementing should specify how to detect
connection loss (if such connection is necessary). You should follow
the protocol specification and not just make things up. (Unless it's
your protocol specification, in which case you should modify the
protocol specification.)

If you implement without a specification, sooner or later you will get
into a problem where there's some incompatibility between the two ends
and you can't figure out which end to change without risking breaking
existing implementations. Having a protocol specification allows you
to determine where the mistake is and fix it, rather than changing
things and hoping existing code still works.

DS

[Peter Duniho]

Pay close attention to what David's written. I should have been more
clear in my own reply: I was assuming you are designing the application
protocol yourself and have some specific need for this behavior.

Be very sure you're not just randomly enabling "SO_KEEPALIVE" on some
arbitrary application protocol. If you need this feature, you need to
be able to include it in the specification for the protocol, which you
can't do if you're implementing some pre-existing protocol.

Pete

[magi...@gmail.com]

Dear
Did you solved this problem ? I have same problem and if you can give me any advice it will be great help

[Lőrinczy Zsigmond]

Situations like this cannot be detected automagically...
use one or more of these:

* heartbeat messages
* TCP.KEEPALIVE (also check SIO_KEEPALIVE_VALS)
* non-blocking mode
* timeout (SO_RCVTIMEO)