How to send a file by a zmq multipart message? - c++

Question

I'm trying to send a video using a ZeroMQ infrastructure and I split the video into chunks to send it. When I do it and put the video into a vector to send it through zmq::send_multipart I get a very high usage of RAM memory and so times later I get a segmentation fault error.
My headache is that when I comment on the line that sends the multipart message and runs the program, the vector is made normally and I don't get the segmentation error, although the consumption of RAM memory is not so heavy.
Can someone give me a tip about how to send this file?
Server code:
#include <fstream>
#include <sstream>
#include <chrono>
#include <thread>
#include <iostream>
#include <future>
#include <zmq.hpp>
#include <zmq_addon.hpp>
using namespace std::chrono_literals;
const int size1MB = 1024 * 1024;
template <typename T>
void debug(T x)
{
std::cout << x << std::endl;
}
//Generate new chunks
std::unique_ptr<std::ofstream> createChunkFile(std::vector<std::string> &vecFilenames)
{
std::stringstream filename;
filename << "chunk" << vecFilenames.size() << ".mp4";
vecFilenames.push_back(filename.str());
return std::make_unique<std::ofstream>(filename.str(), std::ios::trunc);
}
//Split the file into chunks
void split(std::istream &inStream, int nMegaBytesPerChunk, std::vector<std::string> &vecFilenames)
{
std::unique_ptr<char[]> buffer(new char[size1MB]);
int nCurrentMegaBytes = 0;
std::unique_ptr<std::ostream> pOutStream = createChunkFile(vecFilenames);
while (!inStream.eof())
{
inStream.read(buffer.get(), size1MB);
pOutStream->write(buffer.get(), inStream.gcount());
++nCurrentMegaBytes;
if (nCurrentMegaBytes >= nMegaBytesPerChunk)
{
pOutStream = createChunkFile(vecFilenames);
nCurrentMegaBytes = 0;
}
}
}
int main()
{
zmq::context_t context(1);
zmq::socket_t socket(context, zmq::socket_type::rep);
socket.bind("tcp://*:5555");
std::ifstream img("video2.mp4", std::ifstream::in | std::ios::binary);
std::ifstream aux;
std::vector<std::string> vecFilenames;
std::vector<zmq::const_buffer> data;
std::ostringstream os;
std::async(std::launch::async, [&img, &vecFilenames]() {
split(img, 100, vecFilenames);
});
img.close();
zmq::message_t message, aux2;
socket.recv(message, zmq::recv_flags::none);
//Put the chunks into the vector
std::async([&data, &aux, &os, &vecFilenames]() {
for (int i = 0; i < vecFilenames.size(); i++)
{
std::async([&aux, &i]() {
aux.open("chunk" + std::to_string(i) + ".mp4", std::ifstream::in | std::ios::binary);
});
os << aux.rdbuf();
data.push_back(zmq::buffer(os.str()));
os.clear();
aux.close();
}
});
//Send the vector for the client
std::async([&socket, &data] {
zmq::send_multipart(socket, data);
});
}
Client-side:
#include <fstream>
#include <sstream>
#include <iostream>
#include <thread>
#include <chrono>
#include <string>
#include <zmq.hpp>
#include <zmq_addon.hpp>
#include <queue>
#include <deque>
#include <future>
#include <vector>
using namespace std::chrono_literals;
template <typename T>
void debug(T x)
{
std::cout << x << std::endl;
}
int main()
{
zmq::context_t context(1);
zmq::socket_t socket(context, zmq::socket_type::req);
socket.connect("tcp://localhost:5555");
std::ofstream img("teste.mp4", std::ios::out | std::ios::binary);
socket.send(zmq::buffer("ok\n"), zmq::send_flags::none);
std::vector<zmq::message_t> send_msgs;
zmq::message_t size;
std::async([&send_msgs, &img, &socket] {
zmq::recv_multipart(socket, std::back_inserter(send_msgs));
while (send_msgs.size())
{
img << send_msgs[0].to_string();
send_msgs.erase(send_msgs.begin());
}
});
}

Answer 1

An attempt to move all data via multipart-message does collect all data into one immense BLOB, plus add duplicate O/S-level transport-class specific buffers and the most probable result is a crash.
Send individual blocks of the video-BLOB as individual simple-message payloads and reconstruct the BLOB ( best via indexed numbering, having an option to re-request any part, that did not arrive to the receiver-side ).
Using std::async mode with a REQ/REP seems to be a bit tricky for this Archetype must keep its dFSA interleaved sequence of .recv()-.send()-.recv()-.send()-...ad infinitum... as it falls into an unsalvagable mutual deadlock if failed to do so.
For streaming video (like for CV / scene-detection), there are more tricks to put in - one of which is to use ZMQ_CONFLATE option, so as to send but the very recent video-frame, not losing time on "archaic" scene-images, that are already part of the history, and thus delivering always but the very recent video-frame to the receiving-side processing.