Version 23 of iocpsock

Super fast sockets for windows NT/2K/XP, no joke.

docs (not done yet): [L1 ]

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.

TODO list:

Fix the core so the Tcl_ChannelType structure contains vectors for channel transfering [L2 ]
finish the zero-byte receive mode.

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

Category Package | Category Performance