How to get over 65000 bytes in a C ++ socket using recv ()

Based on the comments above, you don't seem to understand how it works recv

or how it should be used.

You really want to call recv

in a loop until you know the expected amount of data has been received, or until you get a "zero read byte" result, which means the other end has closed the connection. Always, no exceptions.

If you need to do other things at the same time (probably with the server process!), You probably want to first check that the descriptor is ready with poll

or epoll

. This allows you to multiplex the sockets as they become available.

The reason you want to do it this way is never different from the fact that you don't know how the data will be sent and how (or when) the packets will arrive. In addition, recv

it makes no guarantees as to the amount of data read at a time. It will offer what it has in its buffers at the time you call it, no more and no less (it can block if there is nothing there, but then you still have no guarantee that any particular the amount of data will be returned when it resumes, it might still return, for example 50 bytes!).

Even if you are only sending, say, only 5000 bytes, it is perfectly correct for TCP to split it into 5 (or 10 or 20) packets, and for recv

- 500 (or 100 or 20), or 1) bytes at a time, each time when you call it. This is how it works.
TCP makes sure that whatever you send will eventually reach the other end or result in an error. And it makes sure that everything you send comes in order. This does not guarantee anything else. First of all, it does not guarantee that any particular amount of data will be ready at any given time. You must be prepared for this, and the only way to do this is to call recv

multiple times. Otherwise, you will always lose data under some circumstances.

MSG_WAITALL

should in principle make it work as you expect, but this is bad behavior and is not guaranteed. If the socket (or some other structure in the networking stack) operates on a soft or hard limit, it may not match your request. Some of the limitations are also unclear. For example, the number for SO_RCVBUF

should be twice as large as you would expect in Linux due to implementation details.

The correct behavior of a server application should never depend on assumptions such as "it fits into the receive buffer". Your application should be prepared, in principle, to receive terabytes of data using a 1 kilobyte receive buffer and, in the case of 1 byte blocks at a time, if required. A larger receive buffer will make it more efficient, but what does it ... it should still work anyway.

The fact that you only see dips above some "huge" limit is just luck (or rather, bad luck). The fact that it appears to "work fine" up to this limit suggests that you are doing the right thing, but it is not. It's an unfortunate coincidence that it works.

EDIT:
As requested in the comment below, this is what it might look like (Code is clearly untested, beware of emptor.)

std::vector<char> result;
int size;

char recv_buf[250];

for(;;)
{
    if((size = recv(fd, recv_buf, sizeof(recv_buf), 0)) > 0)
    {
        for(unsigned int i = 0; i < size; ++i)
            result.push_back(recv_buf[i]);
    }
    else if(size == 0)
    {
        if(result.size() < expected_size)
        {
            printf("premature close, expected %u, only got %u\n", expected_size, result.size());
        }
        else
        {
            do_something_with(result);
        }
        break;
    }
    else
    {
        perror("recv");
        exit(1);
    }
}

      

        
        
        
      

    

This will receive any amount of data you want (or it operator new

doesn't throw away a bad_alloc

few hundred megabytes after the vector is allocated, but that's another story ...).

If you want to handle multiple connections, you need to add poll

either epoll

or kqueue

or similar functionality (or ... fork

), I'll leave that as an exercise for the reader.