When using simple winsock1.1 apis to create and connect a socket, what does an WM_SOCKET / FD_WRITE msg mean? Is the data sent or was it already received?
I'm coding a file transfer tool but am not sure if i can send the next few bytes of the file right after i got the FD_WRITE msg....or does the remote system has to send an answer so my pc can be sure the file data packet was received!?

Posted on 2004-09-21 14:15:02 by Dom
FD_WRITE simply means the socket is reading for writing - in reaction to this event, you can send() some bytes. You cannot be guaranteed that all of the buffer is sent, so you have to buffer your sends...
Posted on 2004-09-21 15:17:49 by f0dder
What exactly do you mean by buffering my data....?
Do I have to watch how many bytes were sent (result of send-call) and should re-call send with those bytes that were not included?
For example when i try to send 2048 bytes and "send" returns that only 1024 bytes were sent, do I have to call "send" again with the remaining 1024 bytes?

Posted on 2004-09-21 16:50:29 by Dom
Exactly - just remember that you shouldn't re-send until you get a new FD_WRITE notification, and that even though you might get a FD_WRITE it's not a 100% guarantee that it's ready anyway. Write robust code :)
Posted on 2004-09-21 16:53:54 by f0dder
thx master 8)
Posted on 2004-09-21 17:06:33 by Dom
file transfer is best done in blocking. either start a new socket on a random port and do file transfer there, or change the socket temp. into blocking mode.
Posted on 2004-09-21 19:39:15 by Drocon
I think the easiest way is when the receiving systems sends an answer after every ~5kb or so, but i'm not sure if this lowers the transfer speed significantly.....
When the sending systems fires out the whole data without waiting for replys i'm afraid the sending systems shows the transfer is already at 100% while a receiver with smaller bandwidth is still processing....therefore the idea with replys...

When I use a blocking socket i cannot use WSAAsyncSelect, i think therefore i need to use winsock2 -> Select-API
Posted on 2004-09-22 05:59:33 by Dom
Blocking sockets with threads are reasonably efficient, EventSelect is good too. The "regular" way of nonblocking sockets using select() can run quite fine too. The main advantage of blocking sockets is that the logic is easier to get right.

The WM_* based WSAAsyncSelect isn't too hot on performance once you get a lot of clients or massive transfer rate though, the messaging system does have a price.

For a file transfer application, I would send the file in chunks - even when using TCP. I would negotiate the chunksize when a connection is established between client and server. This way, you can abort a transfer after a chunk is done, without requiring a separate control connection ala FTP. It would also be possible to add chunk checksums (though they shouldn't be needed with TCP transfers).
Posted on 2004-09-22 09:21:14 by f0dder