TCPROS documentation doesn't match implementations.
A cursory look at the implementation of the C++ and python client libraries seems to suggest the handling of the TCPROS connection header is not exactly the same as what the documentation on the wiki suggests:
The wiki page: http://wiki.ros.org/ROS/TCPROS implies that provision of the message_definition field by a subscriber is mandatory (at least, in version 13 of the wiki page).
However, based on the implementation of validateHeader()in https://github.com/ros/ros_comm/blob/..., it appears that this field is not required in practice, because it is never checked. Further, the implementation also implies that the use of * as a wildcard value for the MD5 sum is supported, even though there seems to be no mention of this in the documentation for the protocol.
The implementation of rospy matches that of roscpp, so that's basically both the reference implementations different to the documentation. This makes client library development pretty difficult:
- What behaviour should a new client library implement?
- Why is
message_definitionrequired to be sent by a subscriber, if the value isn't used for anything? - Why was the wiki page changed from version 12->13, changing
message_definitionto mandatory? - If the protocol specify that the subscriber should send
message_definition, why in actual implementations it's the publisher which replies with this instead? - Is it safe to assume that all publishers will send the
message_definitionfield although they are not required to? - Thus, which fields in the headers are actually mandatory in order to maintain compatibility with all existing ROS implementations? Do some implementations follow the wiki more faithfully?
- Is it actually safe for production code to use the wildcard behaviour?
I didn't write those specs, nor the implementations, but I'm not sure
wiki/TCPROSexplicitly states thatmessage_definitionshould be checked. Only that it should be included in the header sent to a remote recipient.Topics are statically typed. Combined with the MD5, you wouldn't necessarily need the full message definition to determine whether publishers and subscribers are compatible -- that is, assuming the MD5 is correctly calculated on the sending side. If an implementation would so desire, it could recalculate the MD5 on the receiving side and check whether it matches and be extra sure.
Message definitions should be included as it allows things like recording messages (such as
rosbag ...(more).. definitions around.
Logistically it would become really difficult to process
.bags (or look at serialised message traffic in general) without having all messages present on the system that is being used. A good example of this problem is rosjava/rosjava_bootstrap#16 (rosjavadoesn't include the definition (or at least, not the full one) and so.bags recorded with messages originating from that client library are essentially useless without post-processing).I believe
*is used bytopic_tools/ShapeShifter(here).I don't know why that is not documented, but it ..
.. would seem like in general you wouldn't want people to use that value, as it would reduce the usefulness of the MD5 field (just put
*everywhere and suddenly everything is compatible).So that may be a deliberate omission, or a genuine oversight.
On the
Publisherside inroscppit's actually disallowed and enforced by code (here).I would say: yes, but only if you implement it for the reasons
topic_tools/ShapeShiferdoes. Not to circumvent the purpose of the MD5.And finally: seeing the context in which you (most likely) ask this question: there are quite a few alternative client libraries already available. If you're trying to integrate ROS systems into your own (non-ROS) system, it may be worthwhile to look for those to evaluate whether writing a new one would be necessary.
Additionally,
rospycan be used without any other ROS dependencies on your system these days. See Experimental Python package index for ROS for that.And I posted this as a comment as I can't give an authoritative answer here.
It's all based on my understanding of the code and runtime usage of the infrastructure.
@gvdhoorn - Thanks for that info. I might update my question with some more specific points. The need I'm trying to satisfy is for something with similar behaviour to the shapeshifter, accepting unknown messages at runtime, but require to use a language without very comprehensive client library support. So you can see how all this becomes relevant!
@Dirk Thomas wrote rev 12. It's unclear who
unknownentity_1is. @tfoote: any idea?unknownentity_1is an old user from before we were whitelisting users. Thus their username is a pretty good eponym. I suspect that that change was made without any discussion. One of the reasons we want to get away from a wiki.