C++ winsock send arrays

Question

I'm trying to send arrays trough the net with winsock2. Now, i read microsoft disabled sending raw pointers, but you can still send un-edited binary data by casting the pointer to char*:

send(rsock, (char*)&counter, len, 0);

However, the problem is putting the data back in an array when it reaches the client. here, pass is the binary data. That's how I do fot integers, bools and doubles.

    recv(sock, pass, sizeof(int), 0);
    refresh =  (int((void*)&pass));
    recv(sock, pass, sizeof(bool[4800][254]), 0);
    **key = (bool)&pass;
    recv(sock, pass, sizeof(double[4800][254]), 0);
    **mil = (double)&pass;

Integers aren't arrays, while bool and doubles are stored in 2 dimensional arrays. Now, the compiler says this code works for int and bool but for doubles it says "'type cast' : cannot convert from 'char **' to 'double'" "invalid type conversion" even though I'm trying to put raw data in it. Have I done something wrong? Is there any other workaround to send arrays? Thanks in advance.

EDIT: also, I still haven't tried the code with another PC, so I highly doubt the conversion for ints and bools is done right.

Answer 1

Microsoft didn't disable sending anything. The fact is that sending a pointer will simply be of no use to the remote peer. A pointer is simply a memory address, and it is useless to know the address if the information is not there.

The problem you are probably facing is that this array is too big to fit the send buffer, that by default can hold only 64KB.

Pay attention to the return values of send() and recv() to know how much data you actually read/sent in that transaction. It will not always be the same size you told the function to do, as it is often split in pieces smaller than 4KB. You will have to manage the transmission of this information in pieces to fill your entire array.

Answer 2

Have I done something wrong?

Well...

• by default, send and recv don't guarantee to return only after all the buffer you've supplied is either sent or received; they may return as soon as they've enqueued a bit more data for sending, or after receipt of a bit more data that you might be able to process... the buffer size supplied is just an upper limit to your request, not a minimum. If you want to ensure recv doesn't return until the full buffer has been populated, add the MSG_WAITALL flag as a final parameter. For send you must loop sending further parts of your output buffer.

• check you return codes... send and recv tell you of errors and have pretty little numbers that give you clues as to the cause and resolution

• "the compiler says this code works" - no it doesn't... it says your code requests something it's prepared to compile, full of casts that it isn't meant to try to verify, most of which will crash at runtime

Then there's this:

recv(sock, pass, sizeof(int), 0);
refresh =  (int((void*)&pass));
recv(sock, pass, sizeof(bool[4800][254]), 0);
**key = (bool)&pass;
recv(sock, pass, sizeof(double[4800][254]), 0);
**mil = (double)&pass;

I'm not even going to begin to say what's wrong with all that... let's just talk about what might work (might being discussed below):

template <typename T>
void get(int sock, T& t)
{
    if (recv(sock, (char*)&t, sizeof t, MSG_WAITALL) != sizeof t)
        throw std::runtime_error("error while reading data from socket");
}

int refresh;
get(refresh);

bool key[4800][254];
get(key);

double mil[4800][254];
get(mil);

If your sending and receiving systems, compilers, compiler flags, executables etc. differ in any way then this may not work anyway as:

• up until C++03 compilers weren't required to use any particular type to store bool, so who knows if your sending and receiving side will match

• big and little endian systems have different byte ordering which can break naive binary transfers like this

• the size of int may vary

Ultimately, a more robust way to do this would be to use the boost serialisation library.