How to get the buffer from the socket?

You can use the ioctl (in Windows, ioctlsocket ) function with FIONREAD argument, to get the information you want, but never saw it used. Among other things, because when you do recv the value returned by ioctl may already be another (for example, if the data is continually arriving through a connection). This is a typical example of the anti-pattern TOCTOU (see on Google, Wikipedia, etc.).

Your way of trying to use sockets is inverted compared to the mode commonly used. This mode is as follows: you have an X-size buffer, and use this buffer to do repeated reads.

See my answer here for a question about sockets might be helpful.

Are you wanting to predict the size of an unknown stream to pre-allocate a buffer? That does not exist.

• Assuming you can format the message on the server you could add at the beginning a Header with the size of the rest of the message. Common file procedure. But if the connection fails you will have problems with the read () function that is blocking.
• If you can not format the message you will have to deal with large buffers or and it is best to think about working with threads and timeout when read sockets.

An answer I saw in StackOverflow in English on because while(!eof(fd)) is wrong fits here. I'll try to adapt here, and respond: "Why should not you count on the size of the message, even if the operating system offers this functionality?"

At first consider this analysis at a high level of abstraction:

Competition and Concurrency

I / O operations interact with the environment. The environment is not part of your program, and is not under your control. The environment exists concurrently to your program. Like all things competing, questions about an absolute current state do not make sense: the concept of "simultaneity" does not exist at all, as Einstein already said with its general relativity, and Leslie Lamport, at try to establish the order relationship between events that happen concurrently in a distributed system .

More precise: Suppose you ask, "What is the size of the message?". You could ask this to another concurrent thread getting the message, or to the I / O system. But the answer is usually useless, and therefore meaningless. For if the thread says "200 bytes", at the time you read it, it may be that the amount has doubled. No matter what size is reported by the system, this information may have changed at the time you read the message, so the usefulness of this information is limited.

In fact, it is unreasonable to ask the I / O system how an I / O operation will take place in the future. The only reasonable way to handle the issue is to try to carry out the operation, and then deal with the possible consequences of the operation. The moment you interact with the environment, and only then, can you figure out how the operation would go, effectively doing that.

Sockets

How much of the external competing environment does the socket interface actually expose to the programmer? It depends on the protocol. Socket is an abstract interface that gives access to several different communication protocols. Theoretically, it is possible for a protocol to handle all mishaps internally to the socket implementation, and to allow full messages to be received (assuming that the entire messages fit into the buffer). Perhaps UDP allows this processing, considering that its datagrams have a maximum size of 65507 bytes, which fits in the network buffers.

But your code does not use UDP. It uses TCP, and unlike UDP, it is not message-oriented but oriented to stream . There are no logical boundaries between communication units within TCP, and a byte is potentially available to the socket user as soon as it arrives at the network interface. Therefore all the uncertainties of communicating with the outside world are passed on directly to the program.

The correct way to read a TCP socket is to allocate the logical structure that your program expects, and read the socket in a loop until it is populated. For example:

#include <unistd.h>
#include <errno.h>
#include <stdint.h>
#include <stdbool.h>

bool read_full(int fd, void *buf, size_t size)
{
    uint8_t *ptr = buf;
    ssize_t ret;
    while(size > 0) {
        ret = read(fd, ptr, size);
        if(ret <= 0) {
            if(errno == EINTR)
                continue;

            return false;
        }
        size -= ret;
        ptr += ret;
    }

    return true;
}

void func(int fd)
{
    struct my_msg msg;

    if(read_full(fd, &msg, sizeof msg)) {
        puts("Mensagem recebida com sucesso!");

        /* Use msg... */
    } else {
        puts("Falha ao receber a mensagem.\n"
            "Poderia verificar errno para descobrir o que aconteceu.");
    }
}

If you do not know the size of a logical message unit, this should be handled by your application's protocol (for example, each message could have a fixed-length header containing the size of the rest of the message, thus first thing you would try to receive is this header). TCP does not have this information! The information you get with ioctl(_sock, FIONREAD, &size); is useless in TCP communication, because each message sent by the server may have been divided into several datagrams by the TCP layer, and the original size information is not preserved by the network. What you get with this call is the size of the next pending datagram, which is not necessarily the size of the message sent by the other endpoint.