Best practice of sending data of different sizes over the network

I think you can send both in a single datagram if you add a message header.

The sender only sends the amount of payload data it has.

The receiver always requests the maximum payload size but examines the header and the return from recvfrom to determine the actual length.

Here's some rough code that illustrates what I'm thinking of:

struct header {
    u32 magic_number;
    u32 seq_no;
    u32 msg_type;
    u32 payload_length;
} __attribute__((__packed__));

#define MAXPAYLOAD  1024

struct message {
    struct header info;
    unsigned char payload[MAXPAYLOAD];
} __attribute__((__packed__));

void
sendone(int sockfd,const void *buf,size_t buflen)
{
    struct message msg;
    static u32 seqno = 0;

    memcpy(&msg.payload[0],buf,buflen);
    msg.info.magic_number = 0xDEADADDE;
    msg.info.seq_no = seqno++;
    msg.info.payload_length = buflen;

    sendto(sockfd,&msg,sizeof(struct header) + buflen,...);
}

ssize_t
getone(int sockfd,void *buf,size_t buflen)
{
    struct message msg;
    ssize_t rawlen;
    ssize_t paylen;
    static u32 seqno = 0;

    rawlen = recvfrom(sockfd,&msg,sizeof(struct header) + MAXPAYLOAD,...);

    paylen = msg.info.payload_length;

    if (rawlen != (sizeof(struct header) + paylen))
        // error ...

    memcpy(buf,&msg.payload[0],paylen);

    return paylen;
}

The receiver can check the magic number and sequence number to look for corruption or missing/dropped packets, etc.

In fact, you can probably get more efficiency by using sendmsg and recvmsg since they allow you to send a single message using a scatter/gather list. (i.e.) The data would not have to be copied in/out using memcpy from the message struct [you'd only need struct header], so closer to zero copy buffering.

Another option may be to use the MSG_PEEK flag with the recvfrom/recvmsg. I've never used this myself, but it would be something like:

1. Do recvmsg with length of sizeof(struct header) with MSG_PEEK flag
2. Do second recvmsg with length of sizeof(struct header) + msg.info.payload_length

This is just a nicety of not having to always provide a maximum sized buffer. Since it involves two syscalls, it may be a bit slower. But, it might allow allow some tricks with selecting a payload buffer from a pool, based on the type of message and/or length

Unlike TCP which is a stream-based protocol, meaning that calls to recv don't exactly correspond to a call to send, UDP is packet based meaning that each recvfrom matches with exactly one sendto. This also means you need to take care of how large each message you send is.

If you send a UDP datagram that is larger that what can be contained in a IP packet, the UDP message will be fragmented across multiple UDP packets, increasing the chance of data loss. That's something you want to avoid. Also, if you're using IPv6, you'll get an error when you attempt to send because IPv6 doesn't support fragmentation.

What does this mean in relation to what you're doing? It means that, roughly speaking, your messages shouldn't be any larger than about 1450 bytes, so you can use that value as the size of your input buffer. Then you can use the return value of recvfrom to see how many bytes were actually read. If your messages are larger than that, you should break them up into multiple messages.

As with any UDP based protocol, you need to account for the case where messages get lost and they need to be retransmitted, or if messages come out of order.

Actually answer to this question was quite simple.

Given:

unsigned char buffer[BUFFERSIZE];
int bytes = fill_buffer(buffer, sizeof(buffer)): // Returns number of filled bytes.
sendto(socket, buffer, bytes, 0, (struct sockaddr *)&server, sizeof(server))

The return value of recvfrom tells us how many bytes are received, although we make a full read,

int bytesReceived = recvfrom(socket, buffer, sizeof(buffer), 0, NULL, NULL);
// Process bytesReceived number of bytes in the buffer