Instead of creating all the UDP and CAPS message classes and adding them to the source code, we should look at doing the building and parsing at runtime instead. The ProtocolManager to parse the message_template.xml file already exists for the mapgenerator and could be reintegrated into the core library. Basically there would be a message serializer class for CAPS and UDP each which allows to construct and parse the message streams at runtime based on the Block Name and Element Name string. A static MessageElement class would contain constants for those names. When a message arrives only its header gets parsed to determine the message type and then the message is passed along in the system. The final receiver then uses the message serializer methods to retrieve the elements based on Block Name, Element Name and Block Number. In the case of UDP messages the message serializer queries the Protocol Manager to locate the correct offset in the stream, in case of CAPS messages the serializer directly references the OSD data elements.
Alternatively on receiving an UDP messsages it could be directly deserialized into OSD data and then each received message is basically just an OSD data.
Some tests need to be done to find out what the performance consequences for each of these are. The first to only deserialize the message on actual interpretation avoids the overhead of deserializing any and all messages in the simulator loop, moving that burden to the actual consumer, but it avoids almost all work for messages that may never be consumed.
The second solution to deserialize everything to OSD makes everything more uniform, but leaves the deserialization work in the simulator receiver loop and uses up CPU and memory to create potentially large object hierarchies that may be never actually consumed.
Log in to post a comment.
