Hi all,
when using writev() on a TCP socket, I get a behavior that is unexpected, although it may OK by the specification. My test program is using the libc_lwip_loopback plugin.
I create a TCP socket, bind it so some address/port and put it into listening mode. Then, I create another socket, connect to that port and write and IOVEC referencing 3 buffers using writev(). The buffers have a total length of 17 which is returned as a length by the writev().
When reading from the socket using recv(), I'd expect it to return 17 bytes with are identical with the content of the IOVEC. Instead, I need to perform two recv() calls, the first returning the first buffer of the IOVEC and the second returning the buffers 2 and 3 of the IOVEC concatenated.
Find example code here [1].
As I said, this may be perfectly legal behavior. OTOH, Linux and Android behave as expected and there may be code relying on it. Any thoughts on this issue?
Thanks!
Cheers, Alex
[1] https://github.com/senier/componolit/blob/issue16/src/test/mfe/writev_socket...
Hi Alexander,
I share your feeling that it may be better to adopt the behavior of Linux and Android to stay on safe grounds. But on the other hand, I could not find any reference which states that recv() will return a complete TCP segment in all cases (only the opposite, e.g., [1]). Please correct me if I'm wrong. Therefore, any application relying on this fact would be broken. Regarding writev() to the local socket buffer most implementations also seems to gather all data from the iovec in one run. But, this is hidden from the receiver, which has to expect that the data was fragmented on any network layer including the syscall interface.
For these reasons, I suggest we leave the implementation as is for now.
[1] https://stackoverflow.com/questions/3198049/what-value-will-recv-return-if-i...
Greets
Hi Christian,
I agree that applications should be able to cope with that situation and that theres no guarantee about fragmentation in recv(). I will fix the respective test case and hope no real applications do rely on that behavior. I'm OK with leaving the implementation as is.
Thanks!
Cheers, Alex
On 15.08.2017 11:26, Christian Helmuth wrote:
Hi Alexander,
I share your feeling that it may be better to adopt the behavior of Linux and Android to stay on safe grounds. But on the other hand, I could not find any reference which states that recv() will return a complete TCP segment in all cases (only the opposite, e.g., [1]). Please correct me if I'm wrong. Therefore, any application relying on this fact would be broken. Regarding writev() to the local socket buffer most implementations also seems to gather all data from the iovec in one run. But, this is hidden from the receiver, which has to expect that the data was fragmented on any network layer including the syscall interface.
For these reasons, I suggest we leave the implementation as is for now.
[1] https://stackoverflow.com/questions/3198049/what-value-will-recv-return-if-i...
Greets
-
Alexander Senier -
Christian Helmuth