High Load Asynchronous TCP Server & Client Discussion

[Harvey Saayman]

Hey guys I had this at the quick answers section but I'm moving it here cause this is more of a discussion than a particular problem. I've only recently started looking at the .Net asynchronous programming model and I feel that I more or less get the concept. I've started throwing together a server & client that works more or less... But stress testing it yielded very strange results. I think there's something to this asynchronous model that I don't see By stress testing I mean I have a single client(when this works I'll do the same with multiple clients) that sends plain text messages in an infinite loop. The loop has a counter so each message looks like this: 1: My plain text message \r\n[char 3], [char 3] being the packet terminator. I have a 2nd client that receives the messages and just appends them to a TextBox.

Notes:
0) I am using TCP so the packages are guaranteed, right?

1. The server, for now, is just an echo server... I takes a message and sends it to every
   connected client except the one it originated from
2. All 3 apps are done using the asynchronous model

Now when I run all these apps I get very strange results as mentioned before. I see packet 1, 2, 3, 27, 127. Then much later on ill see packet 9 appearing after packet 20000 for example. Some packets are missing characters and some are repeated several times. Quite often the client moans that the server forcibly closed the connection... Nagy Vilmos answered my quick answers question and said

Nagy Vilmos wrote:

If you are expecting high volume then the first thing to do is make sure your receiver takes the data off the inbound queue PDQ and puts it onto a call stack that you manage on a different thread. A regular mistake is to process data directly from the TCP/IP pipe and expext the world to be sunny.

I really hope he sees this cause I'd like to pick his brain! But if not perhaps someone else can clarify... By make sure your receiver takes the data off the inbound queue PDQ and puts it onto a call stack that you manage on a different thread I think he means to NOT process the data in the DataReceivedCallBack... Which makes sense I guess, cause while im processing a piece of data, 20 other pieces arrived and somewhere along the line something HAS to give in... can someone confirm this assumption? He also mentions to put it in a call stack and process it on a different thread.