Re: Close a blocked socket

Pete, I appreciate your taking time to explain your point.
Mainly because the Winsock API doesn't use exceptions. The exception that
thread is complaining about is completely harmless, and is no different
from any other informational exceptions that occur in .NET. .NET uses
exceptions to convey information. The exception mentioned in that thread
is "by design" according to the docs. And personally, I like it that when
you call BeginAccept you know that you'll wind up in your callback
whatever happens. Stops me from wondering if that async result just got
discarded or is still hanging out somewhere when I abort an i/o operation.

Here I disagree with you completely. To me a callback that contains a
reference to a disposed object is an indication of a flawed design. Sure the
callback should happen no matter what, but under no circumstances should it
contain a reference to a disposed object. Not by design. In my eyes it is a
serious flaw - there should be a mechanism where the socket would report
that it is not functional and should be disposed. Instead the system
discards the socket, and the program code finds out about it the hard way.
The fact that I can work around, as everybody else does, is not good excuse.
Async Socket under Win32 would always send a message to the registered
window so the program code could respond accordingly and close the socket
upon FD_CLOSE and analyze the wParam to determine whether the connection
was closed gracefully or was interrupted. Under .NET Sockets the only way to
determine on the server side that the client socket gracefully disconnected
is when EndRead() returns 0 bytes. It works, but it is an odd approach. If
the client disconnected disgracefully, then the program code 'finds out'
when the BeginSend() fails or less often, when EndReceive() generates an
exception. It does not happen too often, however under Win32 these
situations did not occur at all. Program code would become 'aware' of the
disconnect and never try an action destined to fail. With 30 connections it
is not a big deal, but with larger number of connections it could become a
problem. Exceptions take much longer time to process, then regular code.

Michael

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.tqlj39hk8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Tue, 10 Apr 2007 16:21:26 -0700, Michael Rubinstein
<mSPAM_REMOVEr@m®ubinstein.com> wrote:

Pete, interesting arguments. I am basically on the same path, except
that I took a different turn - you decided to go blocking, me -
non-blocking

I didn't "decide to go blocking". I'm just pointing out situations in
which I believe blocking is fine, or perhaps even preferable.

I am running up to 30 simultaneous connections over the Internet and can
easily scale up to 100 or more if the needed. Poor men's IIS.

That doesn't show scalability. Scalable is being able to handle tens of
thousands or hundreds of thousands of connections.

I am not impressed by .NET Socket class. I rewrote my servers and
clients in .NET, complete rewrite from Win32. I don't see any
benefits on the socket side except for the PR part (oh .NET, good).

I don't see how with only 30 connections you'd see any difference. But if
you are not using IOCP, then as you approach tens of thousands of
connections, .NET Sockets will outperform a straight Winsock
implementation.

If I can find the link, I'll post it. Someone else here in this newsgroup
has used .NET for a truly large system and shown that it scales extremely
well.

In any case, the question isn't whether .NET performs BETTER. It's
whether it performs worse.

If it offers similar performance, but in the programming environment
provided with .NET, then it's better for the person doing .NET
programming. I've seen no indication that .NET performs worse than
Winsock, and because it's easier to take advantage of IOCP under .NET
Sockets than it is to do so under Winsock, most applications will show a
clear performance benefit using .NET Sockets over Winsock, because those
applications wouldn't have been done using IOCP in Winsock (and of course,
of the programmers who do attempt to use IOCP under Winsock, many of them
will get the implementation wrong...again, points for .NET).

There is another thread today:
'BeginAccept Callback problem'. Touches on the problem with asynchronous
socket callbacks. Not much of a problem to worry about, except that under
Win32 it did not exist.

Mainly because the Winsock API doesn't use exceptions. The exception that
thread is complaining about is completely harmless, and is no different
from any other informational exceptions that occur in .NET. .NET uses
exceptions to convey information. The exception mentioned in that thread
is "by design" according to the docs. And personally, I like it that when
you call BeginAccept you know that you'll wind up in your callback
whatever happens. Stops me from wondering if that async result just got
discarded or is still hanging out somewhere when I abort an i/o operation.

Some connections will fail. If you are better of handling failed
connections (on both sides) using blocking sockets, then good for you.

I'm not saying it's better off. I'm saying that one is neither better off
nor worse off. The question is failed connections is irrelevant to the
question of blocking vs. non-blocking.

I have good connection to the Internet on the server side. However,
clients use laptops on wireless lans. They shutdown their machines
literally - fold the laptop and walk out of the office. My servers
handle it quite well. If I would choose the blocking path, I would
probably ruin the project.

There's absolutely no reason that using blocking sockets should "ruin the
project" in the usage scenario you describe. You can handle
disconnections just as easily with blocking sockets as with non-blocking.

Pete


.

Relevant Pages

  • Re: API Design: Is Socket.Select() seriously busted?
    ... outcomes-also causes inefficiencies because catching and handling exceptions ... directly from VS2005 help for Socket class: ... Win32 Winsock there was no need for using error trapping when responding to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: socket calls send recv error handling questions
    ... There should not be any exceptions thrown from socket calls, ... example, that after you recva command the next recv, which gets some ... The WinSock calls don't throw C++ exceptions. ... My fear is that a heavy traffic network could ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: error handling
    ... >> Lisa Pearlson wrote: ... >>> Imagine I have a socket read function.. ... >>> exit 1 ... > exceptions to return data yet allow additional info.. ...
    (comp.lang.tcl)
  • Re: Handling exceptions in Socket Callbacks
    ... You're correct the asynchronous socket methods give more opportunities ... I always handle exceptions in callbacks in the callback itself. ... why im using this complicated method of socket communication - ...
    (microsoft.public.dotnet.general)
  • Re: Async socket & active connections
    ... The "blocking = true" in the disconnect phase seems to solve the ... Socket and TcpClient, ... blocking connection somewhere down the line. ... 300K connections, enough to start worrying... ...
    (microsoft.public.dotnet.languages.csharp)