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.
Printable View
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.
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.
the thing is, it crashes the programs, when the buffer is too small.
but what about the recv()?
> but what about the recv()?
Same thing
Underneath it all, they're pretty much the same
Post some code
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
}
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????
well the funny part is that it stops crashing once I enlarge the buffer!
but anyway, what can I do about the small buffer?
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?
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.
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.
People gave up on trying to help solve that problem. I think you're missing the point....
Quote:
Originally Posted by Salem
If you post the relevant code, then people may actually be able to have an attempt at telling you what causes the crash.Quote:
Originally Posted by Salem
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);
. . .
}
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 :mad: :mad: :mad: :mad:
That is what I always do!Quote:
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".