Network programming

[Jon Davis]

Assuming I stay clear of CLR / managed code as this is intended to be
optimized for speed as a Windows service, what is the best and easiest API
for TCP and UDP network programming? I've been told I should stay away from
MFC's CSocket because it's profoundly buggy... or something. Target
deployment environments are Win2000, WinXP, Win2003, and WinVista.

Thanks,
Jon

[Carl Daniel [VC++ MVP]]

Jon Davis wrote:

Assuming I stay clear of CLR / managed code as this is intended to be
optimized for speed as a Windows service, what is the best and
easiest API for TCP and UDP network programming? I've been told I
should stay away from MFC's CSocket because it's profoundly buggy...
or something. Target deployment environments are Win2000, WinXP,
Win2003, and WinVista.

Frankly, your best bet would be to use .NET 2.0. It wraps up a very
sophisticated async socket model using IO Completion ports that's a lot of
work to reproduce. Real-world experience has shown that it's possible to
scale a .NET sockets app to support 1,000,000 simultaneous users on a single
machine (granted, a 16-way Itanium with tons of memory, but still...).
Don't make the mistake of dismissing a CLR-based solution because "it will
be too slow", because very likely it wouldn't be.

That said, you'll get the best performance by mimicing what .NET does - use
async reads and writes and IO completion ports. You can get at all of that
through the Win32 API. I'm sure there are some high-quality IOCP-based
sockets libraries for Windows "out there" as well - I'd suggest letting
Google do your walking for a bit and see what you can turn up. If nothing
else, you can do as programmers have done for decades and reinvent the
wheel yourself.

-cd

[Bruno van Dooren [MVP VC++]]

Frankly, your best bet would be to use .NET 2.0. It wraps up a very

sophisticated async socket model using IO Completion ports that's a lot of
work to reproduce. Real-world experience has shown that it's possible to
scale a .NET sockets app to support 1,000,000 simultaneous users on a
single machine (granted, a 16-way Itanium with tons of memory, but
still...). Don't make the mistake of dismissing a CLR-based solution
because "it will be too slow", because very likely it wouldn't be.

The 'too slow' argument is not important for most situations, as other
things are the most likely bottlenecks.
There is a CLR port of Quake2 with good performance, so the CLR is by no
means slow.

That said, you'll get the best performance by mimicing what .NET does -
use async reads and writes and IO completion ports. You can get at all of
that through the Win32 API. I'm sure there are some high-quality
IOCP-based sockets libraries for Windows "out there" as well - I'd suggest
letting Google do your walking for a bit and see what you can turn up. If
nothing else, you can do as programmers have done for decades and
reinvent the wheel yourself.

I have programmed a socket service myself using Winsock. It's not so hard to
create a Winsock application if you read the MSDN docs and check out the
samples from the platform SDK.
But be aware that you have to do all error handling, threading design, ...
yourself. That wil cost you lots of development time.

All of your platforms run .NET2.0. I suggest you create at least a pilot
application in .NET2.0 to see it the 'too slow' argument is true for your
case or not.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"