http://sf.net/projects/iocpsock

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

docs (not done yet): [http://sourceforge.net/docman/display_doc.php?docid=23086&group_id=73356]

[http://iocpsock.sourceforge.net/netio.jpg]
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 [http://sourceforge.net/tracker/index.php?func=detail&aid=875701&group_id=10894&atid=310894]
   * 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 now that these 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.
----
[Category Package] | [Category Performance]