How to send vector of vector using ecal

[piyushmz]

I'm trying to send a vector of vector using ecal. I tried this thing in iceoryx but the vector need a static values in it. Thanks.

[FlorianReimold]

Hi Piyush,

eCAL (and Iceoryx as well) work by sending raw memory blocks around. There are no "message formats" or similar (at least on on the lowest abstraction layer), but just a pointer to some memory accommodated with the size of the memory chunk.

An std::vector however works differently. If you take an std::vector<std::vector<int>> as an example, the inner int-vectors will be spread their data all around the memory. They will not be stored one-after-another. The outer std::vector of vectors only holds the vector object, that knows where the data is, but doesn't contain it. So a pointer to the start of one contiguous memory chunk doesn't exist, because the data is not stored in contiguous memory.
If you are up for some learning, maybe you should get familiar with the basic Stack & Heap Memory concept. The outer vector object itself is probably on the stack, whereas the data is stored on the heap. https://www.geeksforgeeks.org/stack-vs-heap-memory-allocation/

What you will need to do is get rid of the C++ std::vector and switch to some serialization library (like protobuf) that makes sure all your data ends up in contiguous memory after serialization. You can look at the eCAL Documentation to get started with that. In protobuf you can use a repeated field containing other protobuf messages or a variable-length type like bytes. This way, you can model a vector of vector in protobuf.
Check out the protobuf types documentationv for more information.

You could also switch to raw C structs and manage your memory yourself. As long as you make sure all data ends up in contiguous memory, you can send it out. I wouldn't recommend this though, as it is way more work and you may discover many pitfalls like endianess, variable alignments, integer sizes etc.

Kind Regards
Florian

[piyushmz]

hi @FlorianReimold sorry for late reply as I was trying some new things. Can we insert a vector of vector of vector(3DV) in protobuf? I tried serializing 3DV using a boost lib but sending that was also a challenge.

following is my sturct which I need to convert to protobuf

struct lane_coordinate
{
    float32_t x;
    float32_t y;
};

struct lane
{
    iox::cxx::vector<lane_coordinate, 100> l;
    uint32_t ptsPL;
};

struct lanePerFrame
{
    iox::cxx::vector<lane,100> lanes;
};

struct Lanes
{
    iox::cxx::vector<int,100> camID;
    iox::cxx::vector<lanePerFrame,100> lanepf;
};

I've tried some things but I'm failing to create a proto file for this sturct. The important question-> is it possible to convert this struct to proto file? else what approach should I take to send a 3DV.

[FlorianReimold]

Hi Piyush,

Any serialization technique that can serialize to a concurrent blob of memory would be fine, as long as you are able to de-serialize it on the other side, again. Protobuf just happens to be very convenient and is well supported by eCAL with additional convenience functions.

You can usually 1:1 translate a struct like that by replacing struct with message and make vector a protobuf repeated field.

syntax = "proto3";

package proto_messages;

message LaneCoordinate
{
  float x = 1;
  float y = 2;
}

message Lane
{
  repeated LaneCoordinate l     = 1;
  uint32                  ptsPL = 2;
}

message LanePerFrame
{
  repeated Lane lanes = 1;
}

message Lanes
{
  repeated int64        camid  = 1;
  repeated LanePerFrame lanepf = 2;
}

[piyushmz]

@FlorianReimold Thanks for your time I was stuck with this for quite some time. Appreciate your efforts. I've tried it and implemented using ecal & protobuf. It WORKS! I've shifted from iceoryx just a quick question; Like iceoryx does ecal provide a zero copy. As iceoryx uses iox-roudi to handle the deadlocks and other things. ecal does the same right? or is there any catch I missed here.

[FlorianReimold]

First of all: Please don't get hyped by the zero-copy paradigm too much. In the end this only optimizes out 1 memcpy and from experience I can say that for most software there are lower hanging fruits to optimize on than one that single memcpy. RAM is pretty fast.

But yes, eCAL has a zero-copy mode, that is however disabled by default. And - obviously - it only refers to the Shared Memory transport layer. eCAL also supports UDP and TCP for network communication, which for apparent reasons cannot be made zero-copy. You can enable the zero-copy mode globally in the ecal.ini or on a per-publisher base from your code.
https://eclipse-ecal.github.io/ecal/advanced/layers/shm.html#zero-copy-mode-optional

I would recommend you to leave the default mode (non-zero-copy), as long as you don't have strong reasons to do otherwise. There are some downsides with zero-copy, e.g. that a subscriber can block the publishing of new messages.
Keep in mind, that using a serialization library like protobuf will never enable you to be fully zero-copy anyways, as the serialization and deserialization step by design always creates a copy. Also the serialization and de serialization needs some CPU performance, as protobuf optimizes on serialized message size, not on runtime speed. If you need the utmost performance you will get much more effect by ditching protobuf and creating your custom packed memory structs (or using another serialization library that effectively does effectively that), than you would get by enabling zero-copy.