After a relaxing holiday in France with some friends I now return to coding! I can feel my tan wearing off already as I enclose myself in my room, fingers tapping away on the keyboard, screen glaring its artificial light onto skin which for a few sweet days had basked in the glow of real sunlight!
But that's for losers.
Anyway, the problem right now is the size of the steps I'm taking. The initial traffic analyzer design was simple enough because it didn't attempt to interpret the MySQL packet payloads in any significant way. It discarded unprintable characters and dumped the rest to the console or to a file. Right now, however, I've assigned myself the task of actually interpreting the data I'm receiving and this is not quick or easy.
The problem lies in the passive nature of the system. As with the design of any complex piece of software, you have to think long and hard about what can go wrong. In the case of a packet capture-based system where the input is variable and comes from unpredictable sources this is very much the rule of thumb. I am designing and implementing classes which will differentiate between connections and store data about those connections in discrete storage systems for later processing.
Due to the nature of MySQL packet payloads, only the initial connection handshakes really hold data about who is logging on to the server and what the server's capabilities are. Subsequent packets are aimed at a specific socket which is handled by a MySQL thread spawned for the given session, with all related session data assembled during the initial handshake. The difficulty in aping this system is high, especially when you consider that the auditing system may be executed after the initial handshake packets have already been sent. Little contingencies like that have to be planned for.
So right now I'm putting together a fairly complex set of classes which will identify packet's related session, understand the nature of those packets in terms of their purpose and extract relevant data from them.