recvfrom with less than available bytes
-
I am curious about a situation I have run into. I am hacking a program that was originally meant to read/write serially (serial port) into using UDP. I'm trying to preserve as much of the original code as possible for reasons that I won't bother you with here. The situation is that a ReadCom() function is called with a specific number of bytes that the calling function wants. For example, when the buffer to be read from has 22 bytes in it, the ReadCom() may be called asking for only 16 bytes. Another ReadCom() will be called later asking for the remainder. When I replace the serial port reads with a recvfrom(), it looks like the entire UDP message is gone after the first read even though I only asked for a partial number of bytes. I have two people here telling me different things. One says this should not happen - it is a FIFO, another saying that any time a recvfrom call is made, the entire UDP packet is cleared. Which is it? The behaviour seems to match with it being cleared but I would like to know what you think. BTW - I have tried using the ioctl with FNIOREAD to see how many bytes are available and it does say that 0 are available on the second read.
-
I am curious about a situation I have run into. I am hacking a program that was originally meant to read/write serially (serial port) into using UDP. I'm trying to preserve as much of the original code as possible for reasons that I won't bother you with here. The situation is that a ReadCom() function is called with a specific number of bytes that the calling function wants. For example, when the buffer to be read from has 22 bytes in it, the ReadCom() may be called asking for only 16 bytes. Another ReadCom() will be called later asking for the remainder. When I replace the serial port reads with a recvfrom(), it looks like the entire UDP message is gone after the first read even though I only asked for a partial number of bytes. I have two people here telling me different things. One says this should not happen - it is a FIFO, another saying that any time a recvfrom call is made, the entire UDP packet is cleared. Which is it? The behaviour seems to match with it being cleared but I would like to know what you think. BTW - I have tried using the ioctl with FNIOREAD to see how many bytes are available and it does say that 0 are available on the second read.
The second person is right on - when dealing with UDP you will get the data you ask for and any remaining data in the datagram/message/packet is lost. That is the way things work with a "unreliable protocol" like UDP. I would suggest using a larger buffer, copying all available data to that buffer, and you can then look at that buffer for additional data if required. Note that if the data is serial, you likely want to get it in order. If you send multiple UDP packets, they may arrive out-of-order, or some may not arrive at all. You will want to use TCP sockets if that is going to be a problem. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
I am curious about a situation I have run into. I am hacking a program that was originally meant to read/write serially (serial port) into using UDP. I'm trying to preserve as much of the original code as possible for reasons that I won't bother you with here. The situation is that a ReadCom() function is called with a specific number of bytes that the calling function wants. For example, when the buffer to be read from has 22 bytes in it, the ReadCom() may be called asking for only 16 bytes. Another ReadCom() will be called later asking for the remainder. When I replace the serial port reads with a recvfrom(), it looks like the entire UDP message is gone after the first read even though I only asked for a partial number of bytes. I have two people here telling me different things. One says this should not happen - it is a FIFO, another saying that any time a recvfrom call is made, the entire UDP packet is cleared. Which is it? The behaviour seems to match with it being cleared but I would like to know what you think. BTW - I have tried using the ioctl with FNIOREAD to see how many bytes are available and it does say that 0 are available on the second read.
To add to James' excellent reply....this is from the docs: "If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recv generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost;" Better to recv the exact datagram size or more to make sure you get the etire datagram :) Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot? Of course you don't, no one does. It never happens. It's a dumb question... skip it."
-
To add to James' excellent reply....this is from the docs: "If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recv generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost;" Better to recv the exact datagram size or more to make sure you get the etire datagram :) Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot? Of course you don't, no one does. It never happens. It's a dumb question... skip it."
Mark Salsbery wrote:
To add to James' excellent reply
'Danka! :)
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
Mark Salsbery wrote:
To add to James' excellent reply
'Danka! :)
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesJames R. Twine wrote:
'Danka!
de nada :laugh:
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot? Of course you don't, no one does. It never happens. It's a dumb question... skip it."
-
The second person is right on - when dealing with UDP you will get the data you ask for and any remaining data in the datagram/message/packet is lost. That is the way things work with a "unreliable protocol" like UDP. I would suggest using a larger buffer, copying all available data to that buffer, and you can then look at that buffer for additional data if required. Note that if the data is serial, you likely want to get it in order. If you send multiple UDP packets, they may arrive out-of-order, or some may not arrive at all. You will want to use TCP sockets if that is going to be a problem. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles