Sockets - Intensive I/O Issues

[mcljava]

I have a Sockets based client using the Async model under C# .NET (i.e. BeginReceive, EndReceive, etc w/ non-blocking socket). I have noticed that under intensive I/O scenarios that the TCP logic (in CLR?) seems to overflowing my buffer. This happens only when I build for release, as you could image when building for debug the extra stack, heap, and instrutions executed tend to mask the problem. I was wondering if anyone has developed a I/O intensive packet handling hunk of code and what pitfalls, and/or recommendations do you have? Open to suggestions... Mike

[leppie]

I have seen TcpClient reorder packets under 'heavy' load. xacc.ide-0.1 released! Download and screenshots

[mcljava]

That does not surprise me, when I was using TcpClient I was not please with the level of control I wanted without restoring to lots of translation to the underlying Sockets interface. So... I switched to System.Net.Sockets interface and use the Berkely/Winsock approach. All goes well until heavy load when for some strange reason the BeginReceive() function chokes with a corrupted arg list. Note, my app uses a 2 stage read. Stage 1 is read the fixed length Message Header which contains the Type and Length of the payload. Stage 2 is read the variable length payload. I am wondering if I need to do any special initialization to accomodate a data stream that is flinging messages in size from (12 bytes to roughly 6K) at a real time rate proportional to the the number of calls handled per second across a call center with roughly 500 agents, i.e. the firehose I alluded to earlier. Typically we are talking 1.5 to 3 calls per second, plus all sorts of other events such as Agent State changes, Monitors, etc. Mike