TCPConnection: Handle Joined Messsages about rosintegration HOT 6 OPEN

It might be easier to get the gist of the UE4 log in an image;

from rosintegration.

Another update here: I updated my ROS nodes so that I'm downsampling the point cloud massively (see https://github.com/aaronsnoswell/ue4_comms_test/blob/master/src/pcl_downsampler.cpp). When I do this, I am able to recieve the sensor_msgs/PointCloud2 messages fine. As such, this definitely seems to be a problem with receiving large bson messages that are split over multiple TCP packets.

Can we work out an approach to fixing this problem? I'm happy to do the work if you advise what needs to be done :) I'm not super familiar with the code in TCPConnection.cpp

from rosintegration.

Hi @aaronsnoswell
Thanks for opening this issue and sorry for the delay.
This problem might be indeed a problem with the TCPConnection class.
I think the relevant part starts at

from rosintegration.

As a reference on how it could be done, you can check the implementation on the rosbridge_server side:
https://github.com/RobotWebTools/rosbridge_suite/blob/develop/rosbridge_server/src/rosbridge_server/tcp_handler.py#L62

from rosintegration.

Has this been fixed now? I am just reviewing the code for TCPConnection.cpp and it looks substantially different to what it did in 2018, and appears that it will correctly wait to fill a buffer based on the 4 byte BSON prefix.

However we are still receiving BSON decode issues with our pointcloud frames ("Error on BSON parse - Ignoring message"), using v0.11.10 of rosbridge server. Any clue if this could be related to it?

from rosintegration.

@Sanic

. The main idea is to begin by reading the first 4 bytes. These bytes represent the length field of a bson packet: http://bsonspec.org/spec.html. By reading this length, we can instruct the next recv() calls to receive exactly that many bytes.
After these 4 four bytes have been read, bson_state_read_length will be false. This will cause the jump to

ROSIntegration/Source/ROSIntegration/Private/rosbridge2cpp/TCPConnection.cpp

Line 237 in 7e1716c

std::cout << "Message read mode" << std::endl;

to handle the actual message reception. I guess the problems begin there. Maybe if( _sock->Recv(binary_temp.GetData(), bson_msg_length - 4, bytes_read) ) can return less then the requested bson_msg_length - 4 bytes on fragmented packets. So one would have to reiterate to collect more data in the buffer.

About a year ago I had this exact problem you're describing Sanic, so I modified TCPConnection.cpp to be able to read headers from fragmented packets. I have a pending pull request #179 on this . Would appreciate if someone could have a look at it and accept it if it seems OK. I've been using my modified version multiple times now over the last year without any apparent problem.

from rosintegration.