with the recvfrom() api call, it there a theoretical or physical limit to amount of data read from the socket?
does the tcp layer gurantee all data is reassembled and ordered correctly before being making the data available on the socket so that some application can read the data all at once?
In the following:
The recvfrom() function shall return the length of the message written to the buffer pointed to by the buffer argument. For message-based sockets, such as [RS] [Option Start] SOCK_RAW, [Option End] SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded. For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.
In the SOCK_STREAM case, what exactly does "message boundaries shall be ignored." mean?
Are there other technicalities to be considered when ready large data?
This is on linux/unix OS.
Last edited by Moore; August 31st, 2009 at 09:48 AM.
Reason: addition of OS details
"Message boundaries shall be ignored" means that the bytes in a SOCK_STREAM protocol form a pure stream of bytes that can be broken apart after any byte, such the the bytes returned by any one call to recvfrom will probably not correspond to the bytes that were sent by any one call to sendto.
This is unlike SOCK_DGRAM, where a sender will send a message of (say) 150 bytes using one call to sendto, and the receiver will receive all 150 bytes in a single corresponding call to recvfrom (or recvfrom will fail as described in the docs). SOCK_DGRAM keeps track of the first byte of the message and the last byte, as well as the length of the message.
With SOCK_STREAM, it will not work this way. In SOCK_STREAM, if a sender sends 150 bytes in a single call to sendto, the bytes are not treated like a message; they are treated like a simple stream of bytes, with no difference between any of the bytes. Moreover, since it's a stream of bytes and not a message, there is not even a concept of "length of message". Thus, a receiver might need to call recvfrom many times in order to receive all 150 bytes. Moreover, since the bytes in SOCK_STREAM form a simple stream of bytes, one of the calls to recvfrom might return some of the bytes corresponding to a previous call to sendto or a subsequent call to sendto.
In this sense, recvfrom on a SOCK_STREAM socket acts precisely the same way as recv