Winsock Question: Sending/Receiving Lots of Data

[Max_Power]

Yo!

I am using winsocks to send large amounts of data between a client and a server I am writing and running on my network. I am using non-blocking sockets implemented through WSAAsyncSelect. My questions is: when you are using the send and recv functions to send a receive data is there any limit to how large that amount of data may be? If the data gets split up into multiple packets will you be notified when the first packet is recieved or all of the packets in that send session are received? For example, if the server sends the client 10000 bytes and those 10000 bytes are split into 10 1000 byte packets will I recieve the FD_READ notification when all 10 packets are received or when the first packet is received?

Thanks for reading/help.

[Bros]

Hello

Why don't you put a crc with each of your packet ?
With that, you are sur to receive all the packet, if the crc is not correct, one of the packet is missing or incomplete...

[TNick]

Yes, and when you find a wrong CRC, don't just issue a message on the screen, send a request for the missing packet.

Nick

PS. Just a CRC frustration. I'm off topic, I know. Sorry!

[mnemonic]

I think it is not the case, that FD_READ is send when all data has arrived. The logic of this process lies somewhere in the Winsock DLL.
Lets take the case of the transfer of a 10MB file. It just would make no sense for Winsock to buffer the whole file and then send FD_READ. Besides that, Winsock is just not able to tell how much data is to be sent or received.
How big a certain packet is depends on the underlying hardware (MTU!) and the hardware (routers, etc. ...) between the two socket endpoints.
However, it is just not important to the programmer how big a packet is, because that is handled by the underlying protocols in the OSI-model.

And to the whole CRC discussion: It just makes no sense to try to compute, send and check a checksum with each packet, because the transfer and order is controled by the underlying protocols in the OSI-model. When using TCP it is the job of a different layer to make sure, that all packets are correct (CRC) and are passed to the application layer (where we as the programmers usually work) in the correct order.
However, it makes sense when e.g. transfering some file to send a checksum for the whole file so that the whole file can be checked when the transfer is complete.

HTH

[akane]

If no error occurs, send returns the total number of bytes sent, which can be less than the number indicated by len. Otherwise, a value of SOCKET_ERROR is returned [...]

So, if you ignore the return value, you will have leaks in sent data.
Note, if send returns 0, it means no data was sent, and the socket is still connected.
How many bytes can be put into single send() you can retrieve by calling getsockopt() with SO_SNDBUF option (Buffer size for sends). Every socket allocates memory chunk for buffering data to receive/send, if you pass some MB to send, the socket class will simply copy max [SO_SNDBUF] bytes to send buffer, and return the number of bytes copied. Other bytes are just ignored.
The best algo to send a large nuber of bytes is to have a variable that holds number of bytes already sent, and increase it after every call to send() by the return value, if not -1. You will receive FD_WRITE after every send() if remote host will read more data.