P
Paul Ingles
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
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