Re: Asynchronous Sockets and the I/O Completion Port Model

From: Steve Lutz (slutzNOSPAM_at_comcast.net)
Date: 03/22/04 

Date: Mon, 22 Mar 2004 07:26:07 -0500

Hi Paul,

Have you looked at the TcpClient and TcpServer (in System.Net.Sockets
namespace) classes in .NET? I found these tremendously usefull for writing
Client/Server applications.

Steve

"Paul Ingles" <paul@REMOVECAPSooAbaloAo-dot-com> wrote in message
news:OxtD8s0DEHA.2768@tk2msftngp13.phx.gbl...
> I'm looking to build a TCP based service that will listen for connections
> from a Flash client and I was wondering whether someone could check over
my
> thoughts here and let me know.
>
> It will handle XML messages that are sent by connected clients, process
them
> and then return XML back providing basic instant messaging.
>
> Although it will be providing 2 separate kinds of services, I'd like to
have
> it in one service because of firewall port restrictions.
>
> Broadly messages will be either:
>
> 1) An indication that someone has viewed a web page and indicating they're
> connected to the site, this registers their details to the TCP server when
> they logged in on the site. This connection is also then used to send
> messages to the clients indicating someone would like to start a chat
(which
> then behind the scenes launches another window with the actual IM Flash
> app). Since the flash app will be re-loaded between each page request and
> thus re-start a socket connection this falls into using a thread pool
model
> best. I also estimate it to handle around
>
> 2) Longer lasting connections that handle the IM messages, these contain
> details about the chat session ID so that messages can then be forwarded
to
> the other clients by the server. Although these are long-lived, I'm
guessing
> that the chances of them being high throughput is pretty small so again a
> thread pool model server may be best.
>
> My question is based around the best way to implement the server, I've
been
> reading Network Programming for Microsoft Windows (2nd Ed) by Jones and
> Ohlund as a starting point. They seem to favour the asynchronous model
quite
> strongly, and point out that the .NET Socket class when used on NT-based
> systems using the I/O completion ports model (which in their tests
provided
> the highest throughput and minimal CPU usage).
>
> How does the .NET Async model determine the number of concurrent sockets
it
> can maintain? From what I'd been reading it's necessary to post enough
> Accept/Receive etc. calls that can then be consumed and used instantly, am
I
> right to assume that the .NET Socket class does this itself internally? Is
> it just a case that it accepts as many as it can?
>
> At the moment I have some Asynch Socket code that uses the
ManualResetEvent
> class as a member field of the server's class that is used as follows:
>
> -----
> Console.WriteLine("Waiting for a connection...");
>
> listener.BeginAccept(
> new AsyncCallback(AcceptCallback),
> listener );
>
> // Wait until a connection is made before continuing.
> allDone.WaitOne();
> -----
>
> allDone.Set() is then called at the beginning of the AcceptCallback method
> causing the above code to be executed again, wait for another connection
and
> so on.
>
> Since I'm fairly new to socket programming I was wondering if someone
could
> let me know whether I've misunderstood anything, or whether there's
anything
> else important that I haven't considered.
>
> In terms of processing, I'm hoping it should be reasonably well
performing.
> It'll use .NET's XML Serialisation support to parse the messages, and a
> Hashtable will be used to locate connected Sockets quickly so that with a
> couple of connections active it can find the associated client and send
> messages on. Incidentally, once I have it running as a simple
> console/windows app I'll be modifying it to then run as a Windows service.
>
> I really appreciate your time if you've read down this far, as I said, I'm
> really looking to get some kind of second eye to see if I've not taken
> something into account.
>
> Thanks for any suggestions/comments,
> Paul
>
>