iocpsock

Super fast sockets for Microsoft Windows NT/2K/XP, no joke. This is a simple extension to Tcl that you can load that provides a new channel type for superfast sockets.

docs (not done yet): [1]

Pardon the "noise" in the display. sqlserver running on "rufus" must have been serving-out during the test run. For each time I raised the -sendcap on the sender (the left console), I checked -recvburst on the receiver (the right side console). Notice how the -sendcap is acting as a throttle in the graph. Notice how burst detection is kicking in and raising the WSARecv pool to compensate.

This "burst mode" thing is nice, but I find "flow-controlled" to be the better way for a web server. A -sendcap value of 2 should be sufficient. A -backlog setting of 200 I found to be extremely "bullet-proof" for the front-end.

BTW, the sender console is missing this in the display:

 proc mash s {
    puts -nonewline $s [string repeat Q 4096]
 }

It seems to be as efficient as I can get it. There is one item to note. As it doesn't have any polling behavior at all, events will not be repeated. IOW, if your fileevent readable handler decides not to service a notice to read (doesn't call read or gets) and no bytes follow, it will not be repeated as is the behavior of the core socket driver. tclhttpd doesn't have this issue, but some code might.. Especially the ones that check for EOF before the read, which is backwards.

Other things to note.. now does blocking mode and has an async style close that "lets the instance go" and does a background destroy when the last reference returns. That async close helped concurrency considerably.

This package is still being worked on! OMG. Written and maintained by DG.

WJR - I'm using iocpsock 2.0.1 with TclHttpd 3.5 on Windows Server 2003. I'm seeing lots of these errors in TclHttpd's error log:

 [14/Jun/2004:12:31:44] iocp1044 read error: error reading "iocp1044": connection reset by peer

Can you give me an idea of what this means and whether it's a critical problem?

That means someone made a connection to your server, but then the client dropped the socket. It could mean the server was busy between the time it was accepted by the socket code itself to the time it was accepted into the server by [HttdpAccept] and enough time had passed that the client dumped the socket, but the probability on that is rather low. - DG

WJR - We don't seem to be having problems with the application, and the server isn't very busy. I'm thinking that the problematic requests are coming from our load-balancing hardware, which sends a GET request every 20 seconds to the server to make sure it's active.

DG - Here's a possible explanation.. AcceptEx() (The overlapped method for pre-allocating new sockets onto for the listener [aka. the hand-rolled backlog]) is more low-level than accept(). What might be happening is that for a SYN/RST it returns connected, but reset for when the WSARecv is put on it, instead of being ignored/recycled.. Hmmm. I'll ask on the winsock list to see if this might be true. FWIW, AcceptEx() can actually return all error codes that ConnectEx can return, such as WSAEHOSTUNREACH, WSAETIMEDOUT, etc.. AcceptEx() isn't explicitly documented to do this and shocked me when I discovered it.

DG - Found an easy way to reproduce it. Use IE6 and hold Ctrl+R to force refreshes. Yeah, AcceptEx() comes back without an error, but the first WSARecv fails. I'll debug this tonight to see if I can ignore this getting up to Tcl's acceptProc.

UPDATE 6:20 PM 3/28/2005

The current development HEAD for IOCPSOCK v3.0 contains full support for IPv6 with IrDA inprocess. IPX/SPX is next on the list. AppleTalk, ATM, DecNet, ISOtp4, NetBIOS, and Vines are all possibly candidates as well! UDP and other packet based protocols are *not* possible until either a redisgn of Tcl's channel system supports message-based I/O or a really good hack has been done to force it properly.. DG

MHo 2009-02-04: Unfortunately I had to drop the use of iocpsock in the latest version of Tclhttpd Winservice, because of diffuse intermittently errors (http downloads of large files stop at different stages, leaving the file (and socket) handle open) which I cannot track down.

DG 2009-03-22: I can't track it down either if you don't give conditions to reproduce. MHo: If I find time, I'll prepare a Server with iocpsock and some demo files, put it all together into a zip for downloading.

AMG: Is this code of any use, or has it been incorporated into/superseded by modern Tcl I/O?

APN 2014-05-22: IPv6 is now part of the Tcl core of course (8.6). None of the other stuff is in the core, in particular the performance improvements, which would require significant arch changes. So I would say yes, this extension is very much of use even today.

AMG: Is there a fundamental reason why iocpsock is and will always be faster than the Tcl core I/O? Is the architecture of the Tcl core I/O inescapably burdened, or can iocpsock's improvements be integrated?

DG see [2] for details on differing I/O models for windows network programming. iocpsock uses the the top one in the list: GetQueuedCompletionStatus(). Stock Tcl uses the win3.1 compatible WSAAsyncSelect() method