-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prototype of fragmented message support. #11
Prototype of fragmented message support. #11
Conversation
@smoriemb Thank you so much for your awesome contribution as "OTOSHIDAMA"!! 🙄 In my understanding, this PR can be checked with https://github.com/smoriemb/mros2-mbed/tree/feature/mros2-frag-msg-proto that was mentioned at mROS-base/mros2-mbed#32. And also, this PR needs to add changes to mros2 and mros2-mbed repositories. Are they correct? Could you also create PRs to mros2 and mros2-mbed repositories that associate with this PR? I'm so curious about the Limitation: Statefull Write is not supported. However, I cannot properly understand how this limitation affects the product. In my opinion (or strategy), I want to locate only If you can agree with my opinion, could you move My understanding is that you want to create the very long string from README.md by the below method. But I think that we simply need to prepare long_text.txt for this requirement. And also, I think that modifying CMakeLists.txt will need to be maintained for future use. |
In my understanding, the PR works well without the other PRs because I added only an interface that is not used by the existing mROS2.
I've created the related pull-requests below.
The limitation does not affect the existing mROS2 because the Stateful writer is used only for the discovery system. However, if mROS2 extends its feature to use Stateful writer for normal messages, we will have to consider how we can extend the fragmented feature to use for reliable communication.
I've already added the message type in the above pull-request of mROS2.
Could you kindly continue to discuss this in the thread below? |
Thank you so much for your kind operations. I will check your PRs. I knew you were right about all the updates being included in this PR, but now it is easier to review each update and I can merge each of them at once if there are no problems. We will review them ASAP! |
@smoriemb long, long, and seriously long time no see,,, We will merge your fantastic work in due course! |
add note about PR #11, that is the specific modification for mros2
It involked a warning message when we use CMake environment. ``` ./embeddedRTPS/src/entities/StatelessReader.cpp:73:8: warning: extra tokens at end of #endif directive [-Wendif-labels] 73 | #endif SLR_VERBOSE ```
This pull request is to add a fragmented data sending feature to embeddedRTPS.
I added a send-message-interface newChangeCallback() receiving a function object instead of a pointer to a buffer that includes a message to be sent (like the original "newChange()") .
The function object is expected to serialize one fragmented data each time embeddedRTPS sent the fragmented data to the lwIP layer.
The type of the function object has a return type, as below.
where the first is the pointer to the fragmented data and the second is the size of the data. If there is no data to be fragmented, the function object returns zero size and embeddedRTPS perceives the end of the fragmented data.
The sender thread (progress()) of embeddedRTPS checks if each history cache has the function object, or not. If yes, it treat the history cache as a fragmented data and calls the function object. If no, it treat it as a non-fragmented data and do the exsiting procedure.
Limitation: