Figure out the size of a datagram

So I was perusing the c++ and networking tags on S.O. today and I kept bumping into separate but similar questions on how big to make a buffer in which one would recv a datagram of an unknown size, and I kept on seeing these massive numbers like 4000 bytes and such. I found this a bit ridiculous, though I understand it’s probably quite necessary. The thing is I don’t really like the idea of having to allocate these massive buffer sizes, and along the way amidst my perusing I found a post that stated I could recv without actually consuming data using I think it was NO_BLOCK. Recv is supposed to return the number of bytes read, yes? So my question is could I just allocate the correct block size using
 
void * block = malloc(recv(sock, NULL, 1000000, NO_BLOCK));

Safely without having the datagram be dropped? Also am I even thinking of the right macro name??
Last edited on
Heh nvm I forgot I actually have a reference manual for a reason XD


Edit: alright so far I’ve found a mention of a MSG_PEEK flag...
Last edited on
And... that’s all I could find. :( anybody got any insights for me? MSG_PEEK seems like it would work, but I’ve yet to come across a single person who’s considered it. Why?
> void * block = malloc(recv(sock, NULL, 1000000, NO_BLOCK));
The maximum UDP size is constrained by the MTU size of your connection, and that's never anywhere near a megabyte.

https://stackoverflow.com/questions/900697/how-to-find-the-largest-udp-packet-i-can-send-without-fragmenting

Your theoretical upper bound would appear to be 64K.
https://serverfault.com/questions/246508/how-is-the-mtu-is-65535-in-udp-but-ethernet-does-not-allow-frame-size-more-than
You might be able to get that in a LAN setting with lots of tinkering, but out on the WAN, something is sure to negotiate/limit that down to the MTU.
That’s just an arbitrarily large number, it’s not an actual size. As you can see I pass a null pointer as the buffer, so it’s not meant for making a buffer of that size. It is simply so that I don’t accidentally cut off the amount of bytes that are actually in the datagram with my imaginary limit. If the limit is actually 64k, then I guess I would revise it to be something like

 
void * block = malloc(recv(sock, NULL, 1 << 15 , MSG_PEEK));


Sadly that doesn’t really answer my questions though. Those are actually the questions that I encountered myself that about this post.

Edit: or well the first one is one of them anyways.
Last edited on
Again with the mythical invention of API capabilities
https://linux.die.net/man/2/recv
You can't pass NULL to recv.

> It is simply so that I don’t accidentally cut off the amount of bytes that are actually in the datagram with my imaginary limit.
So what's wrong with
- calling recv with a large buffer to actually fetch the data,
- finding out how large the actual datagram is from the return result of recv,
- then calling malloc to create another buffer to store that data,
- followed by a memcpy?
...waste of space? And not to mention a memcpy doesn’t seem like a great performance booster. I guess I’ll just have to settle for the large buffer. Hm. Or maybe use realloc to shave the size after.. eh. Oh well. Thanks!
How else do you imagine the lower levels work?

Do you know how astonishingly fast memcpy is to compared to drips of information you get out of a network connection?

How many of these buffers are you keeping hold of until you finally get around to doing something with them?

I'm beginning to smell an xy problem.
http://xyproblem.info/
1) I don’t understand this statement / question. What are you referring to in what I’ve said?

2) yes. When you put it that way yes that’s true I see where your coming from.

3 & 4) the presented problem is the entirety of the situation, so I wouldn’t know. One? Two? Idk.
Topic archived. No new replies allowed.