Close a blocked socket

[=?Utf-8?B?TWlrZVo=?=]

I have a sync socket application. The client is blocked with
Socket.Receive( ...) in a thread, another thread calls Socket.Close(). This
unblock the blocked thread. But the socket server is still connected. Any
idea?

Thanks.

[Michael Rubinstein]

Use asynchronous non-blocking sockets. Implementing blocking sockets in
situations where connections may fail is looking for trouble.

Michael

"MikeZ" <Mi***@discussi ons.microsoft.c omwrote in message
news:50******** *************** ***********@mic rosoft.com...

>I have a sync socket application. The client is blocked with
Socket.Receive( ...) in a thread, another thread calls Socket.Close(). This
unblock the blocked thread. But the socket server is still connected. Any
idea?

Thanks.

[Peter Duniho]

On Mon, 09 Apr 2007 18:10:00 -0700, MikeZ
<Mi***@discussi ons.microsoft.c omwrote:

I have a sync socket application. The client is blocked with
Socket.Receive( ...) in a thread, another thread calls Socket.Close().
This unblock the blocked thread. But the socket server is still
connected. Any idea?

What does "the socket server is still connected"? Do you mean that the
server's socket for the connection (the one returned in the accept call
when the client connected) doesn't indicate that the connection has been
closed or reset?

If so, you should probably check your linger options. If you use a zero
timeout when closing a socket, then the connection is simply aborted
without a graceful shutdown and the server won't know that the connection
has been closed. IMHO, it's better to use the Shutdown method first, to
explicitly initiate a graceful shutdown rather than relying on the
behavior of the Close method (since what it does depends on a variety of
other things).

All that said, since the connection could be aborted for other reasons
without the server being notified, you still logic in the server to deal
with that condition. A graceful shutdown is nice, especially to ensure
that pending data that has been enqueued for sending really gets sent.
But there's no way to guarantee one, so your server needs to be prepared
to deal with the case when it doesn't happen.

Pete

[Peter Duniho]

On Mon, 09 Apr 2007 19:50:20 -0700, Michael Rubinstein
<mSPAM_REMOVEr@ m®ubinstein.co mwrote:

Use asynchronous non-blocking sockets. Implementing blocking sockets
in situations where connections may fail is looking for trouble.

I disagree. There are a variety of reasons to use non-blocking sockets
rather than blocking, but the criteria "where connections may fail" is not
one of them (and is meaningless anyway...since any connection can fail,
using that as a reason to not use blocking sockets would mean no one would
ever use blocking sockets for connection-oriented protocols, which is
obviously not the case).

Pete

[Michael Rubinstein]

Pete, you are right. Mike did not mention failed connections.

Michael

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Mon, 09 Apr 2007 19:50:20 -0700, Michael Rubinstein
<mSPAM_REMOVEr@ m®ubinstein.com wrote:

> Use asynchronous non-blocking sockets. Implementing blocking sockets
in situations where connections may fail is looking for trouble.

I disagree. There are a variety of reasons to use non-blocking sockets
rather than blocking, but the criteria "where connections may fail" is not
one of them (and is meaningless anyway...since any connection can fail,
using that as a reason to not use blocking sockets would mean no one would
ever use blocking sockets for connection-oriented protocols, which is
obviously not the case).

Pete

[=?Utf-8?B?TWlrZVo=?=]

Peter,

In Server, the Socket.Connecte d property is TRUE even this socket is closed
by client.

I implemented a socket pool in server side, I need to know a socket status,
and close the socket, so other client can open a new socket when pool reach
the max number.

The server side is Async socket, and client is Sync socket. I found when
server is sending data to client, and client close the socket, server know
the socket is disconnected. When server does not send any data to client, and
client close the connection, server still think the socket is connected.

Anyway, I am using the last sending time to control the socket pool. It is
not perfect.

Thanks.

[Peter Duniho]

On Tue, 10 Apr 2007 05:07:35 -0700, Michael Rubinstein
<mSPAM_REMOVEr@ m®ubinstein.co mwrote:

Pete, you are right. Mike did not mention failed connections.

Well, what I meant was that even if he did mention failed connections,
that's not an argument against blocking sockets.

You may not be in agreement with that opinion. :)

[Peter Duniho]

On Tue, 10 Apr 2007 09:48:01 -0700, MikeZ
<Mi***@discussi ons.microsoft.c omwrote:

[...]
The server side is Async socket, and client is Sync socket. I found when
server is sending data to client, and client close the socket, server
know the socket is disconnected. When server does not send any data to
client, and client close the connection, server still think the socket
is connected.

As I wrote in my previous message, you may want to look at the linger
options for the socket, and/or simply use Shutdown before calling Close on
the socket.

If you just close the socket on the client side without doing a graceful
shutdown of the connection, the server isn't notified and you wind up with
exactly the situation you're talking about.

Pete

[Michael Rubinstein]

Pete, my opinion is that blocking sockets should be used only when there
is a compelling reason for doing so. I must admit, I can't name a single
one. Must be my ignorance <g>. I suspect the popularity of blocking sockets
is more due to the fact that earlier (8 years or so) MSDN examples use
blocking sockets, while non-blocking Winsock samples were published later
and are less known.

Michael

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Tue, 10 Apr 2007 05:07:35 -0700, Michael Rubinstein
<mSPAM_REMOVEr@ m®ubinstein.com wrote:

> Pete, you are right. Mike did not mention failed connections.

Well, what I meant was that even if he did mention failed connections,
that's not an argument against blocking sockets.

You may not be in agreement with that opinion. :)

[Peter Duniho]

On Tue, 10 Apr 2007 12:58:12 -0700, Michael Rubinstein
<mSPAM_REMOVEr@ m®ubinstein.co mwrote:

Pete, my opinion is that blocking sockets should be used only when
there is a compelling reason for doing so.

I can agree with that. But "compelling reason" is in the eye of the
beholder.

I must admit, I can't name a single one.

Personally, I see no reason to not use blocking sockets if one is dealing
with a very simple situation (say, peer-to-peer application where you only
ever have one connection). Before .NET, using plain old Winsock, I would
extend this to be a simple situation in which there's no window message
pump, since WSAAsyncSelect is a pretty easy and convenient way to handle
socket i/o without adding a new thread.

In .NET, the async use of Sockets is quite nice and, even more important,
scales very well due to its use of IOCP. But it may be easier for a
programmer to conceptualize his i/o algorithm by dedicating a thread or
two to the socket i/o and using blocking sockets. It is much more
important for the code to be written correctly than for it to be written
using some particular paradigm, and if using blocking sockets advances
this goal of correctness, then it seems to me that's a good reason to use
blocking sockets.

In the simple scenario I mention above, I certainly see no real advantage
to using the Begin/End pattern over straight blocking sockets.

But my main point is that whatever one thinks about blocking versus
non-blocking, I really don't see how the question of whether a connection
can fail or not comes into it.

Pete