0

I'm programming in C.

Suppose that I receive a datagram with Berkely socket UDP. I receive 20 bytes. So I have a char buffer[20] where I can memorize this data.

Now I want to use the first 4 bytes as an int and the other as a char.

int varnumber;
memset(buffer,0x0, 20);
recvfrom(sd, buffer, 20, 0, (struct sockaddr *)Addr, &Len);

So if I want put into "varnumber" I have written this code:

varnumber=*((int *)&(buffer[0]));

This way is correct? If it isn't how can I do this? I can't change the packet received from the socket.

P.S.

I send from a server this datagram in order. Every datagram has a counter in this 4 bytes. So for example, I have:

datagram1: 00000000 00000000 00000000 000000001 ...(other char)...

datagram2: 00000000 00000000 00000000 000000010 ...(other char)...

ecc...

I tried to printf varnumber for a lot of datagrams received. I read the numbers all in perfect order, but from 93 onwards I read jumps straight to number 1001.

I tried to see these packets on Wireshark and Wireshark doesn't show any problem, in fact If I visualize the counter in the datagram in the time order I see the correct order. My c program doesn't read 93 but read 1001. I don't know why.

I know that UDP does not guarantee the order, but I'm in localhost and this is so strange. It is also a problem that I always see, it is not occasional.

ABC
  • 71
  • 9
  • 1
    You need to make sure you get the octets in the proper byte order for your CPU. Shifting and adding each octet is a better approach. – David R Tribble Sep 21 '20 at 16:45
  • Answer updated. – ABC Sep 21 '20 at 16:49
  • Maybe [this question and its discussion](https://stackoverflow.com/questions/41978340/how-to-read-4-bytes-of-data-from-a-given-char-pointer-in-c) can help you. – NXP5Z Sep 21 '20 at 17:28
  • I have the same problem with memcpy. So I'm thinking that the problem isn't the byte order but It's a problem with UDP. Why I visualize all ok on Wireshark and with my client not? – ABC Sep 21 '20 at 17:39
  • 1
    I'd suggest you print the raw data from `recvfrom()` byte-by-byte in hex, and compare that with what you see in Wireshark. If I were in your position, I'd want to check whether the problem was in the data I was receiving, or the way my program was interpreting it. I'd echo the view of @DavidRTribble that you would do better to assemble the bytes into an integer using arithmetic, rather than doing a cast that will only work on some CPU architectures. – Kevin Boone Sep 21 '20 at 17:55
  • Wireshark visualizes packet with correct values. Shouldn't this be enough to say that there are no problems with the transfer? – ABC Sep 21 '20 at 19:41
  • Any idea to solve my problem? – ABC Sep 22 '20 at 08:31
  • 1
    Can you share another structure between sending and receiving software? send/receive directly from/to a struct? an `int` could be placed at a naturally aligned offset within a struct and store/load the `int` with `htonl()` and `ntohl()` – Milag Sep 22 '20 at 14:45
  • suggest inserting a `sleep( 1 )` in the server transmit loop to see if the rate of incoming packets is overrunning the ability of the client to process those packets – user3629249 Sep 23 '20 at 21:02
  • suggest removing: `memset(buffer,0x0, 20);` because the call to `recvfrom()` will completely overlay that buffer. – user3629249 Sep 23 '20 at 21:07
  • regarding: `recvfrom(sd, buffer, 20, 0, (struct sockaddr *)Addr, &Len);` strongly suggest checking the returned value to assure the operation was successful – user3629249 Sep 23 '20 at 21:08
  • Please post a [mcve] so we can reproduce the problem and help you debug it. – user3629249 Sep 23 '20 at 21:09

0 Answers0