Figure out the size of a datagram

[highwayman]

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??

[highwayman]

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...

[highwayman]

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?

[salem c]

> 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.

[highwayman]

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.

[salem c]

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?

[highwayman]

...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!

[salem c]

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/

[highwayman]

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.