RecordReplay.cxx
Posted: Wed Jul 18, 2007 6:58 pm
This is continued from http://my.bzflag.org/bb/viewtopic.php?t=11149 . Because of the nature of the post, I don't think it belongs there anymore. I posted there about wanting to create indexes for replay files, where the index allows you to search using various criteria to find files and index points.
I have spent several hours with RecordReplay.cxx now, and have a strategy for proceeding, but since the modifications I need to make are rather substantial I wanted to post for advice about proceeding. First, the following things are clear:
(1) As a meteorite pointed out, the current plugin API cannot handle the needed modifications, since they would require intercepting (network) packets either at load time or at send time, and doing something else with the data. This could be cured with changes to the API, but it is not celar what to request, as the API seems to have no way of handling packets directly. I'm reluctant to make such a request, because it looks like a big modification to me, and it's probably not anyone's priority but mine.
(2) The RecordReplay.cxx file is a masterful 53 page (yes I printed it to appreciate it in its full glory) tangle of C header, and C/C++ code. It records games by brute force (putting network packets into files), and plays them back by reading the packets and sending them out again. This actually has its advantages, but aspects of the design might be due to be re-thought. For one, it's a feature of every server that is turned on or off, by configuration, so it will be there whether it is used or not. The whole interface with record/play and the rest of the server might be simplified if most of it could be moved to the plugin environment, say by providing an API function or two for handling packets as they are sent. This would permit other kinds of plugins to be written to make recodings, e.g. that are anonymized or something. Low-level packet packaging would have to be kept out of the plugin environment, and this may be challenging. All of this would be a fairly major re-factoring, and I wonder what people think of the merit of it as an undertaking.
(3) The best way forward for me at the present moment appears to be to attempt a more modest revision of RecordReplay.cxx, along the following lines: (a) create a new command "/replay makeindex" or the like, whcih accepts a filename for indexing, (b) borrow code from the replay file loader and loadPacket to accomplish parsing of the file, (c) borrow other parts of the code to write the packets in indexed form. Actually, I just need to make the packet contents readable at this point, until I can make some decisions about what the indexes need to look like.
Does anybody have any reactions to any of the above?
Thanks in advance,
gnu-sense
I have spent several hours with RecordReplay.cxx now, and have a strategy for proceeding, but since the modifications I need to make are rather substantial I wanted to post for advice about proceeding. First, the following things are clear:
(1) As a meteorite pointed out, the current plugin API cannot handle the needed modifications, since they would require intercepting (network) packets either at load time or at send time, and doing something else with the data. This could be cured with changes to the API, but it is not celar what to request, as the API seems to have no way of handling packets directly. I'm reluctant to make such a request, because it looks like a big modification to me, and it's probably not anyone's priority but mine.
(2) The RecordReplay.cxx file is a masterful 53 page (yes I printed it to appreciate it in its full glory) tangle of C header, and C/C++ code. It records games by brute force (putting network packets into files), and plays them back by reading the packets and sending them out again. This actually has its advantages, but aspects of the design might be due to be re-thought. For one, it's a feature of every server that is turned on or off, by configuration, so it will be there whether it is used or not. The whole interface with record/play and the rest of the server might be simplified if most of it could be moved to the plugin environment, say by providing an API function or two for handling packets as they are sent. This would permit other kinds of plugins to be written to make recodings, e.g. that are anonymized or something. Low-level packet packaging would have to be kept out of the plugin environment, and this may be challenging. All of this would be a fairly major re-factoring, and I wonder what people think of the merit of it as an undertaking.
(3) The best way forward for me at the present moment appears to be to attempt a more modest revision of RecordReplay.cxx, along the following lines: (a) create a new command "/replay makeindex" or the like, whcih accepts a filename for indexing, (b) borrow code from the replay file loader and loadPacket to accomplish parsing of the file, (c) borrow other parts of the code to write the packets in indexed form. Actually, I just need to make the packet contents readable at this point, until I can make some decisions about what the indexes need to look like.
Does anybody have any reactions to any of the above?
Thanks in advance,
gnu-sense