recv() and recvfrom()

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:

Code:

---

while (recv(sockfd, buf, 100, 0)>0)
{
  // do something with buf
}

---

but since you say recv() must accept all, this won't work.

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

>
Post some code

---

Quote:

---

Originally Posted by Salem

>
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 post the relevant code, then people may actually be able to have an attempt at telling you what causes the crash.

never mind :)

I've found the problem.

Code:

---

main()
 {
  char msg[400]={0};

  something(msg);

  . . .
 }

int something(char *msg)
 {
  . . .
 
  recvfrom(sockfd, msg, 400, 0, (struct sockaddr *)&ina, &addr_lnt);

  . . .
 }

---

I guess the recvfrom() overflows the msg string, and because msg is a parameter to the something() function, it causes the program to crash.

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:

Quote:

---

Or at the very least make the size a #define and make sure you use it everywhere.

---

That is what I always do!
But you see, the question is why recvfrom() overflows msg?
it's like recvfrom() doesn't even care about "max buffer size".

OK, it's possible that you have found a serious easily reproducable bug in Windows 98 that no one has noticed for the last six or so years. However, before we can send off a report to bugtraq and notify CERT you're going to have to post a compilable reproduction of the problem.

Seriously, this thread is 16 posts long and we still haven't got enough information to actually look at the problem. If you're not prepared to post the code I suggest this thread be closed as trying to guess at the problem is simply wasting everyone's time.

I did post some code, but if you really believe that the full code will help, there you go:

Code:

---

#define DNS_LNT 500


int DnsLookup(char *dns_server, char *host_name, char dns_id, char dns_type, char *msg)
 {
    int sockfd, numbytes, addr_lnt, tot_lnt;
    struct sockaddr_in ina;

    tot_lnt = DnsSetMsg(msg, host_name, dns_id, dns_type); 
/* this only sets a DNS message and returns the length */
    if ((sockfd=socket(AF_INET, SOCK_DGRAM, 0))==-1)
      return(0);

    ina.sin_family = AF_INET;
    ina.sin_port = htons(DNSPORT);  // port 53
    ina.sin_addr.s_addr = inet_addr(dns_server);
    memset(ina.sin_zero, '\0', 8);

    if ((numbytes=sendto(sockfd, msg, tot_lnt, 0, (struct sockaddr *)&ina, sizeof(struct sockaddr)))==-1)
      return(0);

    memset(msg, '\0', DNS_LNT);
    addr_lnt = sizeof(struct sockaddr);
    if ((numbytes=recvfrom(sockfd, msg, DNS_LNT-1, 0, (struct sockaddr *)&ina, &addr_lnt))==-1)
      return(0);

    closesocket(sockfd);
    if (msg[1]!=dns_id)
      return(0);
    return(1);
 }

---

Still not enough sorry. We don't know how msg is declared. We don't have the code in DnsSetMsg that also uses the msg buffer. We don't know the value of tot_lnt that is passed to sendto that also uses the msg buffer. We don't have the code after the return from DnsLookup. Remember the effect of clobering memory may be delayed.

It is easy to overrun while converting a domain name to the 3www9alltheweb3com0 format and it positively hard to avoid all buffer overrun scenarios when unpacking the reply and decompressing the domain names.

Post the rest of the code and we'll have a look.

You're asking all the wrong questions, the only important thing that's missing is the declaration of msg:
char msg[DNS_LNT]={0};

All of the problems where in recvfrom(), nothing else matters, when (if) the program died, it died on recvfrom().

note: at the end of DnsLookup() the msg contains the entire dns response, with all the answers, so it's pretty big.