Has anyone attempted to record DDS traffic without using the recording service? We need to record and playback dds data, but we're unable to use the recording service because we're using VxWorks for our OS, and don't have access to a Windows or Linux machine during operation. I've browsed the forums and have deduced some potential options:
- Use Dyanmic Data API to subscribe to DDS data and serialize/deserialize to a file
- Use Transport Plugin API to create a custom transport that does the same as option 1, but still use all other built-in transports (similar to example: http://community.rti.com/examples/creating-custom-transport)
- Have RTI port recording service to VxWorks for us
- Currently not an option simply based on time
Are these my only options? Does anyone have any other recommendations?
Thanks,
Mike
Hi,
I will try to answer your question regarding the tradefoffs
(1) Implement an application using the Dynamic Data API
This is certainly possible. Just recording the data is not so hard, especially if you are OK storing it in serialized format. You can get some ideas on how to do this from the MonitoringData.java example that is n the File Exchange.
Doing the replay, however, is significantly more complex because you will have to store not only the data, but also the type information so that you can create a DataWriter with the same type, handle pacing of the read of the data and publication repecting the original timing, etc.
There are also issues of replay configuration regarding the QoS used, handling the fact that that there could be multiple versions of a Type even for a single topic, etc. Soon you will also want to have remote control of teh recrd/replay process, etc. All in all it seems like a lot of work...
(2) Use Transport Plugin API
I do not think this is a practical option. You would be recording the RTPS messages, that by itself is OK. But then you cannot just replay as such because they are lower level messages that contain sequence numbers, GUIDs, reliability meta-traffic (Heartbeats, NACKs, repairs) which all depends on the actual applications and timing. If you just replayed this traffic later it would make no sense to the receivign application (e.g. you will not be sending the right repairs to the NACKs you got and the timign would be wrong, etc.)
The traffic you recorded with the transport-plugin is basically what you can record using Wireshark or TCPdump. Not somethign that is easy to understand or replay to an application.
(3) Have RTI port recording service to VxWorks for us
This certainly seems the most practical of the three options.
As to other options... What version of VxWorks are you using? What is the processor architecture?
Depending on your VxWorks platform and your timing I could perhaps offer another option. If your VxWorks is one of the standard ones for which we have a board setup we could try to do a quick "experimental" build for you. Assuming we do not run into issues with the file-system access in VxWorks and it all works, we could make that available to you via the community portal. This means it will not be fully tested and you could use it "as is" with no support. You can then try it in your system and decide whether it is OK as is or contact your RTI representative to come up with an arrangement so that we can do a complete test, offer you support, and incorporate it to our supported platforms...
This is a bit of a short in the dark. If this "experimental port" does not work then having the "official port" would seem to me the most cost-effective option.
Gerardo
Gerardo, thanks for the detailed reply.
Option 1:
We realize that playback would be slightly more difficult than simply recording the data, but we still haven't ruled this option out. I've implemented the monitor data and monitor types examples found in the File Exchange and have that working. I still havent had success in being able to store the dynamic data to a serialized format. I saw that each dyanmic data sample has a "to_stream" function but i havent had success yet with sendind the serialized data to a stream, which in my case would be a file.
Option 2:
We didn't think this option was practical, so i'm glad you don't either :)
Option 3:
I agree that this would be the ideal option, however cost constraints aside, we simply don't have the time to have a full port done. I think recording the data would be a good start for now, and we'd be very open to test any experimental builds. We're using VxWorks 6.9 running on Intel Ivy Bridge boards.
Hello Mike,
Are you planning to run the recording application in VxWorks 6.9 in Kernel mode or in RTP mode? Does it matter to you? RTI Recording Service uses SQLite and from our initial investigation it seems it would be a lot simpler to get it running on RTP mode.
Gerardo
It doesn't really matter at this point, but I guess running it as a RTP would be ideal.
With regard to option 1, i'm having a hard time understanding how to serailize/deserialize the TypeCode information in order to reconstruct the topics. I was able to serialize a dynamic sample, but the serialized sample is pretty much worthless without its associated TypeCode information (which you already mentioned). I found a function called RTICdrTypeCode_serialize/RTICdrTypeCode_deserialize but I couldn't find anyinformation on how to use those. I'm not sure if i'm on the right track, or if there is a better way to store/retrieve the typecode information. Right now, i'm ignoring QoS data.