Tcl Source Code

View Ticket
Login
Ticket UUID: fc3c425cde46c6996c8543f701fcbeafd2b7ee5e
Title: Use iocpsock as windows socket driver
Type: RFE Version: 8.6.7
Submitter: oehhar Created on: 2017-01-31 20:57:22
Subsystem: 25. Channel System Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Open Last Modified: 2020-01-24 07:10:22
Resolution: None Closed By: nobody
    Closed on:
Description:

Aim of this ticket is to elaborate to use iocpsock (http://sf.net/projects/iocpsock) as a windows socket driver.

The author is David Gravereaux, who provided the following informations by private E-Mail:

As my open license says you can do anything you want with my code, go for it. Yes, please add it to the core.

I had some reservations in 2004 or so when Jeff Hobbs asked me only because I'm a perfectionist.

The thread that processes the completion port could also be used for file and console channel types, too. So that will need to be internally shared in some manner.

I've lost touch with the Win32 API as I don't do programming these days, but I tried to implement a method for creating more than just TCP channel types. I think Microsoft has dropped that since XP was current. Also, there probably isn't much of an interest in Netware IPX sockets anyways.

Has the channel API in TCL gained the support of packet/message based usage yet to support UDP?

When I first wrote the extension, I used a crazy complex way of allowing fine tuning of the amount pre-allocated buffers. Some of it was good such as multiple send buffers and multiple accept buffers for listening sockets, but the rest didn't work for finding an improvement.

For receiving sockets, after deep experimentation, I found that just a single zero sized buffer to act as pure notification while matching the TCP buffer size to the channel buffer size was the best way to do it. Doing the WSARecv() in the ChannelReadable using the channel buffer directly is the most efficient way rather copying from the returning completion port buffers.

User Comments: oehhar added on 2020-01-24 07:10:22:

Thank you, Ashok, this is rocket news! If you want to get in contact with David, please drop me an E-Mail.

Thank you, Harald


apnadkarni added on 2020-01-24 05:48:46:

I've started on an iocp package with the intent of merging into the core at some point. Not based on iocpsock though for multiple reasons.

Only mentioning here in case someone else starts a similar project so I can drop working on mine :-)

/Ashok


ralfixx added on 2019-04-15 13:47:55:
In addition to my observation (posted by oehhar on my behalf, thanks Harald) that I get full channel performance with plain TCL sockets on Windows 10, iocpsock in zero-byte receive mode maxes out at about 44MByte/s, reason unknown.  I had no time to investigate further since plain TCL works just fine...

I'm using a patched TCL which allows up to 10MB as -buffering for any channel (instead of the default 1MB), but that was also the case before on Windows-7 when plain TCL did not work and iocpsock did.

oehhar added on 2019-04-15 11:23:35:

Tombert on clt:

Just for completeness, I had an issue with Nagle's algorithm which I had to disable also on linux to get full performance. https://groups.google.com/forum/#!topic/comp.lang.tcl/xtVodiKNr0I


oehhar added on 2019-04-14 09:39:42:

Ralf fassel wrote on clt 2019-04-11 titled "FYI: doubleplusgood TCL socket performance Windows 10"

I'm in the middle of rolling out a high-data-rate application which we originally provided on Windows-7. The TCL socket performance (of course most probably the underlying Windows-7 TCP/IP stack) was not good enough for the high data rates (Gigabit ethernet, using up to 100MByte/s). Therefore we successfully used the iocpsock extension there (which basically implements a multi-threaded double-buffer reading).

Now on Windows 10 I found that the plain TCL socket performance (of course most probably the underlying Windows-10 TCP/IP stack) has greatly improved and can cope with Gigabit in a single-threaded application. I'm getting datarates above 100MByte/s, dumping them in parallel to SSD and serving a responsive Tk gui. Sometimes the earth *is* a disc... :-)

Needless to say that the same hardware running under Linux never had any problems with these data rates...

R'


anonymous added on 2018-11-05 12:38:04:
After the discussion on mailing list, i joining this request. It would be very nice to have Iocpsock implemented as windows socket driver in core.

I working on multiplatform http upload application where speed is needed. And i was very confused, why on Linux i getting upload speed about 10-11Mbs (upper limit of my internet connection) and on windows only about 2-3Mbs.

I received suggestion from Harald Oehlmann, that i should try Iocpsock package. So i tried and replaced core 'socket' command with 'socket2' command:

package require Iocpsock
package require http
....
rename socket ""
rename socket2 socket
.... 

And it helped!
Now im getting the same speed, about 10-11Mbs as on linux.

I can imagine, that poor performance of sockets under windows may frighten some users and they run away to other language (javascript, python, #C, or whetever is trendy today) And we dont want this, right? :)

Pavel J.