Hey Mayan,
Thank you for your question. We have tried to capture questions and answers like this in the past in the tutorials or FAQ, but there is so much detail in the overall system that we miss important things like this regularly. In JAUS UDP communication, there are two commonly accepted ways to intercommunicate with another JAUS component.
The first is what is commonly referred to as the OPC method. When the JAUS Working Group (WG) decided to do some interoperability testing, the OPC group was formed (I believe in 2003) to facilitate that testing. They realized that a standard needed to be created for how UDP messages were exchanged between JAUS entities. Their decision was to add the "JAUS01.0" bytes to the beginning of each UDP packet. Those 8 bytes are prepended to the standard JAUS message data (i.e. the 16 byte header and message data). We were not part of this decision making process, however we do support it in OpenJAUS as a large variety of organizations use that.
The second method is the more recent SAE standard of JUDP which is defined as AS5669. This transport specification defines a 5 byte header which has information such as the transport version number and information related to a header compression technique (which OpenJAUS does not support) as defined in the AS5669 standard. We support that as much of the testing for the validation of AS5669 was done by JAUS organizations which we have interacted with in the past and many of them have continued to use this interface.
So, that is why you are seeing, respectively, 8 bytes and 5 bytes infront of the JAUS data you expect. OpenJAUS allows the user to select which UDP transport interface they wish to use by configuring values under the Node_Communication and Subsystem_Communication sections of the Node Manager Configuration File. The values JAUS_OPC_UDP_Interface and JUDP_Interface respectively control the two different types. Note that you can only have one type enabled at a time (they both use UDP port 3794). You can see more detail about the config file in the
ojNodeManager tutorial.
Now, to answer your other question, yes this could lead to issues integrating with other JAUS systems. However OpenJAUS was designed with these two implementations in mind as they support 90+ percent of the known JAUS implementations among the participants of the JAUS working group. However, if the extra bytes in the header are an issue for your group, OpenJAUS is designed to be very flexible. It would be a rather simple exercise to take either of the two Transport Interfaces (JausOpcUdpInterface and JudpInterface) and create a third interface which has no prepended data. Then you could add it to the interface enumerated by the subsystem and node communication manager classes and finally add control into the NodeManager.conf file.
If you take such a third approach, I hope you'll contribute the work back as we may have other groups interested in using such an implementation.
Thanks and best of luck!
~Danny
