2

I am having a problem with sending vectors across an enet connection because vectors seem to be represented with their own sort of data possibly pointing to where the vectors internal data is actually stored, and I cannot figure out how to access it.

Both the client and the server have this data structure on them:

typedef struct {
    unsigned int type;
    vector<int> content;
} packetFormat;

The data is being sent to the server like this:

packetFormat var;
var.type = 5; //sizeof is 4 bytes
var.content = {1, 3, 5, 20, 10, 50, 10, 10}; //sizeof is 16 bytes regardless of data
//total 20 bytes, 21 counting \0 character
ENetPacket* packet = enet_packet_create((char*)&var, sizeof(var) + 1, ENET_PACKET_FLAG_RELIABLE);
enet_host_broadcast(client, 0, packet);

The server then receives and casts the data to the same structure like this:

//receives 21 bytes, which is correct
packetFormat* var = (packetFormat*)(event.packet->data);

Checking the variables however, var->type is equal to 5, which is correct but when I try to check the size() or any contents of the vector, it either crashes the server or gives garbage data. As I said before I think this is because the vector thing in the struct is actually a pointer, but does anyone know how to transmit and re-assemble the raw data? Thanks.

Saher Ahwal
  • 9,015
  • 32
  • 84
  • 152
Lemon Drop
  • 2,113
  • 2
  • 19
  • 34
  • Just manually pack it to any appropriate POD type and then send it. Also you should construct vector from POD data on the other side of network connection. – Ivan Velichko Jan 30 '14 at 06:59
  • 1
    @Ostrovski yea I ended up just converting the data to a char vector, sending it and then receiving it on the other end and rebuilding it. – Lemon Drop Jan 31 '14 at 01:31

2 Answers2

1

If understand what you code is doing, it's simply serialising the struct as though it had no indirections, like fixed width datum.

The vector internally has a pointer to it's data, so serialising the vector in the struct you are only sending the value of the pointer, not the actual data itself pointed to by it.

Also there would be very little to absolutely no guarentee that the sizeof and layout of the vector would be the same at the host and the client size.

If you want to send the vector I would consider using a C++ network library that understands vectors, like Boost.Asio for example.

111111
  • 15,686
  • 6
  • 47
  • 62
  • I dont think that I should switch my networking library just because of a small problem like this unless getting the data the vector is pointing to is actually impossible, because that's kinda what I am trying to figure out. – Lemon Drop Dec 27 '13 at 23:58
  • @lemondrop: Boost serialization may be more appropriate. Once you serialize your data into a buffer, you can send that buffer using whatever network library you want. – Vaughn Cato Dec 28 '13 at 00:05
  • @lemondrop, alone I would agree if you were already using a C++ lib, but you appear to be using a C library with C++. That's just not a great combination if you can help it. – 111111 Dec 28 '13 at 00:05
  • I am pretty sure enet is a C++ lib, if not then yea I might use boost or something. I just really dont like libraries like boost that have a billion features in them because I feel like that just slows stuff down. Enet only has the really basic parts of networking inside it allowing for a lot more flexibility but I'll check some other stuff out here. – Lemon Drop Dec 28 '13 at 00:13
  • @lemondrop boost is fairly modular, boost asio has it's on lib it's not one big bloated library. There are others too, like POCO, but I can only recommend Asio first hand. – 111111 Dec 28 '13 at 00:14
  • @lemondrop also, even if enet is written in C++ (which I am not sure it is) it certainly isn't written in a C++ style, which is reason enough not to use it in my opinion (except for the purposes of wrapping it). – 111111 Dec 28 '13 at 00:16
0

insert all the elements of vector in a char* variable of a class. this will create a stream of bytes in memory. at the receiving end, take care of the byte offset from which the vector has to be started to be copied back.