Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve read various sites and tutorials online but I am still confused. If the message is bigger than IP MTU, then send() returns the byte sent. What happens to the rest of the message? Am I to call send() again and attempt to send rest of the message? Or is that something IP layer should take care of automatically?
If you are using TCP then the interface presented to you is that of a stream of bytes. You don’t need to worry about how the stream of bytes gets from one end of the connection to the other. You can ignore the IP layer’s MTU. In fact you can ignore the IP layer entirely.
When you call
send()the TCP stack on your machine will deal with all the details necessary for the stream of bytes that you are pushing into your send calls to appear fromrecv()calls at the other end of the connection.The one thing to remember is that with TCP you are dealing with a stream and that means that one
send()may result in data arriving in multiplerecv()calls and multiplesend()calls may result in data arriving in a singlerecv()call. You have no control over this. You are dealing with a stream of bytes and each call torecv()can return any number of bytes from 1 to the number currently outstanding (allowing for adequate buffers passed to therecv()call).Since the commenters asked for it 😉
On most TCP stacks
send()is most likely to fail to send everything because the TCP stack’s buffers are full and (probably) the TCP window is also full and flow control is in operation which means that the stack can’t send any more data until the remote end ACKs some data and it’s not prepared to buffer any more on your behalf. I’ve not come across a TCP stack that will refuse asend()due to MTU considerations alone but I guess some slimmed down embedded systems might behave that way…Anyway, if
send()returns less than the number of bytes that you supplied it then you should resend the remaining data at some point. Oftensend()will block and wait until it can send all of the data, and if you’ve set the socket into non blocking mode then you probably do NOT want to immediately retry the send if it fails to send everything as you’ll likely end up in a tight loop…It would probably be useful for you to be more specific about the operating system that you’re using.