I've noticed something weird about recvfrom(), it seems that I can't receive udp data in parts, so my buffer must be big enough to except all. Is this normal?
If so, is it the same with recv()?
Thank you.
I've noticed something weird about recvfrom(), it seems that I can't receive udp data in parts, so my buffer must be big enough to except all. Is this normal?
If so, is it the same with recv()?
Thank you.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
UDP is always sent and received as a single message.
If your receive buffer isn't big enough, the remainder is thrown away
So the sender and receiver have to agree on such things.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
the thing is, it crashes the programs, when the buffer is too small.
but what about the recv()?
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
> but what about the recv()?
Same thing
Underneath it all, they're pretty much the same
Post some code
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
well there isn't much to post, but this is what I had in mind:
let say the data is 500 chars long, and my code is:
but since you say recv() must accept all, this won't work.Code:while (recv(sockfd, buf, 100, 0)>0) { // do something with buf }
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
Honestly, it's like getting blood out of a stone sometimes
How the hell do you think we're supposed to tell you why that crashes????
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
well the funny part is that it stops crashing once I enlarge the buffer!
but anyway, what can I do about the small buffer?
Last edited by Devil Panther; 05-15-2004 at 01:30 PM.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
What Salem is politely trying to say is that you need to post your actual code and a little more of it. Preferably, narrow down(using printf(), MessageBox() calls or a debugger) where it is crashing and post several lines above and below that line(declarations are also useful).
As a guess, you are expecting buf to contain a valid string in the code after the end of the while loop. Or some other presumption about the contents of buf. Or you could be using the return value of recvfrom() to index an array. Or... More (actual) code needed.
Or post the file.
well I've done some tests, first recv() is not like recvfrom(). with recv() I can read data in parts, unlike with recvfrom().
and about the crash, I did trace the problem to the recvfrom()!
when the buffer wasn't big enough to contain the entire data, the program crashed on recvfrom(), so I've enlanrged the buffer size and the problem was gone.
so the question remains, how can I tell the size of incoming data using datagram socket?
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
As Salem as already stated, because UDP messages (datagrams) are always recieved and sent as one whole message, the client and server software should already have pre-defined size limits (which *you* decide) on the messages they send to eachother.
This way you should never have a problem with UDP messages being too big for your buffer.
If the message recieved is too large to fit in the buffer, recvfrom() will return SOCKET_ERROR and a subsequent call to WSAGetLastError() will return WSAEMSGSIZE indicating the message was too large. The remainder is thrown away (recv() will do exactly the same), therefore the size of the actual message in total is irrelavent, since you can't actually read it in it's entirety.
[quote]so the question remains, how can I tell the size of incoming data using datagram socket?[/qoute]
recv() / recvfrom() will return the number of bytes recieved if the buffer was big enough. If you're looking for some sort of way to check how big the datagram is *before* you read it, so you can size your buffer, I'm pretty sure it's not possible, and would be bad. Set a standard message size limit, and you won't need to worry about it.
All of this information can be obtained by reading the documentation for the functions in question, and a few search engine crawls.
C/C++ Support IRC Channel
Server: irc.dal.net Channel: #csupport
Come along and help make it a great resource for the community.
I think you're missing the point. When the buffer size is too small ( with recvfrom() ) the program CRASHES, so I can't even check the error type.
could it be because of the system? I'm using win98se.
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
People gave up on trying to help solve that problem. I think you're missing the point....
Originally Posted by SalemIf you post the relevant code, then people may actually be able to have an attempt at telling you what causes the crash.Originally Posted by Salem
C/C++ Support IRC Channel
Server: irc.dal.net Channel: #csupport
Come along and help make it a great resource for the community.
never mind
I've found the problem.
I guess the recvfrom() overflows the msg string, and because msg is a parameter to the something() function, it causes the program to crash.Code:main() { char msg[400]={0}; something(msg); . . . } int something(char *msg) { . . . recvfrom(sockfd, msg, 400, 0, (struct sockaddr *)&ina, &addr_lnt); . . . }
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.
int something(char *msg)
{
. . .
recvfrom(sockfd, msg, 400, 0, (struct sockaddr *)&ina, &addr_lnt);
. . .
}
Proof, if ever proof were needed, that it really is a GOOD IDEA to pass around the buffer size from function to function.
something( buff, sizeof buff );
would have solved all your problems long ago.
Or at the very least make the size a #define and make sure you use it everywhere.
If we travel this road again, of you not pasting code when the solution is so bloody obvious, I'll
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
That is what I always do!Or at the very least make the size a #define and make sure you use it everywhere.
But you see, the question is why recvfrom() overflows msg?
it's like recvfrom() doesn't even care about "max buffer size".
"I don't suffer from insanity but enjoy every minute of it" - Edgar Allen Poe
http://www.Bloodware.net - Developing free software for the community.