views:

31

answers:

1

On Windows I/O completion ports, say I do this:

void function()
{
    WSASend("1111"); // A
    WSASend("2222"); // B
    WSASend("3333"); // C
}

If I got a "write-complete" that says 3 bytes of WSASend() A were sent, is it possible that right after that I'll get a "write-complete" that tells me that some or all of B & C were sent, or will TCP will hold them until I re-issue a WSASend() call with the rest of A's data? Or will TCP complete it automatically?

+2  A: 

I've been developing client and server systems with IOCP for over 10 years now and I've never seen a partial write completion in normal usage. You CAN get them but if you do then the chances are your server is hosed anyway; you'll likely get a write completion with an error of ENOBUFS which tends to mean that you've exhausted non-paged pool or exceeded the locked pages limit.

IMHO you should manage your resources such that you never hit these operating system limits.

If a write completion returns less than the number of bytes that you think you should have written then there's not really much that you can do to recover if you have more writes pending. In the example in your question if A failed then you could only really shutdown the connection as B and C might succeed. In practice you don't have to worry about more than this.

If you know that you don't have any more writes pending on that connection then you COULD issue another write to write the subsequent data.

And TCP doesn't come into this at all.

Len Holgate
Crystal clear - I better put some limits before and not have to deal with it later. So for example, in my LAN here, I have two PCs - one is an FTP server (Serv-U) and the other is an FTP client (FlashFXP); When I upload a file from the client it fills the pipe in a speed which is relative to the LAN's current conditions - how does FlashFXP knows how much to push? Or does do a readl WSASend () one by one (doing the next one as soon as the current has finished)? What do you say?
Poni
Take a look at the FTP RFCs. I've no idea how the protocol is structured for the data transfer side of things. They may have explicit support for flow control in the protocol. There's nothing to say that the server or client uses IOCP; they may use blocking writes and then there is no issue as the stack will simply block your call. And we've done the whole 'write completion driven pacing' to death in other questions.
Len Holgate