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