I've been spending some time away from Project XASM in order to regroup and collect my thoughts.
During this interval, I dusted off my IOCP server engine (an old copy, from before I made it modular), and began tinkering with it.

Duplex is an IOCP Server/Client core which supports some very nice features:
-is 100% asynchronous
-can Listen on multiple Ports
-can handle multiple Protocols on the same Port
-can assign different Protocol Handlers to each individual TCP Session
-can change the assigned Protocol Handler at any time
-can make outgoing connections
-is immune to Zombie DoS attacks
-can support tens of thousands of concurrent TCP Sessions (up to Windows Handle Limit)
-does not rely on CRAP such as 'Scavenger Threads'

Duplex began life as a VOIP engine, and inherently supports full duplex audio streaming with TruSpeech compression (8khz, 16 bit), I just got carried away with the network support.

If this sounds interesting, and you'd like to see the sourcecode and/or test the binary, say so!
Posted on 2007-06-16 00:06:03 by Homer

-is immune to Zombie DoS attacks

If you find a way to immunize against bandwidth saturation, let me know :P

-does not rely on CRAP such as 'Scavenger Threads'

Scavenger threads?
Posted on 2007-06-16 04:54:37 by f0dder

If you find a way to immunize against bandwidth saturation, let me know :P

Last time I talked to Homer about the VOIP Engine project he had going, we were discussing various bandwidth optimization possibilities. He stated at the time he was going to try and get it to eventually be capable of running on a shared network of dialups so bandwidth was always an issue. At that time, most of the ideas were geared towards the audio itself rather than the protocol, but being as long as it's been I wouldn't doubt if he's put some form of bandwidth optimization and protection in place..

** If not that would be something interesting for the next time your bored, Homer ;)

Scavenger threads?

In short, a thread that gathers information/data from the thread pool. Handy in some cases, but tend to lead to hard to track down bugs if your not careful. There are several of them implemented in IIS and even in the Windows NT5.0 scheduler (iirc).

Bryant Keller
Posted on 2007-06-16 19:14:51 by Synfire
hmm wouldnt mind seeing the source and playing with it homer plz
Posted on 2007-06-17 09:51:54 by evlncrn8
Synfire: I was talking about guarding against people maliciously flooding you from a zombie botnet, not optimizing the protocol :)
Posted on 2007-06-17 10:42:01 by f0dder
Synfire: I was talking about guarding against people maliciously flooding you from a zombie botnet, not optimizing the protocol :)

Ah, okay. When you said saturation my first thought was of the flooding that occurs naturally by low bandwidth hosts, which is why I thought you meant about optimizing the protocol. In the case of neutralizing a botnet.. yeah, that would be a bit difficult. The only solutions I can think of are kinda out there and not really plausable for your average server setup (and it wouldn't even be that effective against larger botnets anyways).
Posted on 2007-06-18 18:33:12 by Synfire
I've almost literally driven myself crazy over IOCP - so yes, I'd definately like to check it out.  Does your method require a window (visible or invisible) to function?  I noticed that you specified TCP connections being supported - does it also support UDP listener or server sockets?  Anyway, thanks - I look forward to checking it out.
Posted on 2007-06-27 22:53:43 by Jascwa
Beieng horribly naive - but interested, I found the below of some
use in understanding what the hell you ppl were on about.

Posted on 2007-06-29 01:47:32 by Draakie

Although there is no real requirement for a window of any kind, my Duplex.Init method does expect a hWnd or hDlg, although it does not actually do anything with it, other than set that handle as 'pOwner' for the instance of the Duplex object, which in turn allows any derived protocol objects that you might create to find that window later.. if you didn't care, you could just pass any value you wanted.

My implementation does not support UDP, although that could be done too.

Spent a long while looking for a silly bug - since this is a 'just for fun, until I need it' project, I've been pretty relaxed about the timeframe, but hang in there, I'll post full source very soon, I'm almost done implementing the VOIP protocol handler.

I'm still asking myself why anyone would wish to do some of the funky stuff that Duplex can do, but it tickles me that I can implement crazy stuff like switching protocols midway thru a session anyway :P

Posted on 2007-07-03 12:22:16 by Homer