With windows networking, it's not that hard to saturate a 100mbit LAN, but it's nearly impossible on gigabit. Even if you have your TCP settings correct and can verify that a raw TCP stream can give you at least 900megabit throughput, you'll usualy only get something like 25MB/s throughput via SMB/CIFS v1 (ie, the version used by anything prior to vista SP1). This is regardless of whether you're streamin to/from RAM drives, ie, harddrive isn't the bottleneck.

When SMB/CIFS clients connect, they negotiate a message block size to use, iirc the max is 64kb. I'm not deeply into the protocol specifics, so I don't know whether these blocks have to be ACKed at the protocol level (ie., not just TCP ACK), or if the bottleneck is simply that a new block isn't requested until one full block has been received. But a bottleneck there certainly is.

And this is sort of silly. It should be possible to simply say "receive this file", and then get it streaming at the max speed the network can handle. This would probably even make the protocol work better when used across the internet instead of a LAN.

Sure, there are complications to this "streaming" approach, namely that you need a control-connection AND a data-connection if you want to be able to reliably cancel transfers etc., but it's doable without THAT much fuzz.

blocking socket is slow?
im using them with threads. Each connection create 2 threads, 1 rof recv and 1 for send. On close threads are terminated and memore free.

Ugh, don't let the code police hear that! Might work okay for very few connections, but it's a scalability nightmare. And once you involve that amount of threads, it's not like the code is much simpler than proper async sockets.

Shame on you!