This conversation derives from one which started from a related idea.
@david_griffithsYour “signature” idea is similar to one that’s been floating around for a while (pre-dating this community otherwise I’d share a link) around byte-counting.
The concept, as I’ve always understood it, is that we would match up corresponding file descriptors in two processes, and set a point in each recording where the exchange of data is in sync. From that point we can inspect reads and writes and by counting bytes exactly correlate the flow of bytes between those recordings. There’s a little more work to set the initial “in-sync” point when the fds aren’t opened within the recording, but if you get that alignment then no fuzziness would be required.
This approach might actually be best for you if you want to fully-automate your navigation in twin recordings, but it feels like the improvement to recording wallclock resolution could be very useful in manual navigation relatively cheaply.
bbcounts is silly of me btw because will vary across processes so no relationship to time!
I did some investigation on this a while ago; it’d be good to look into again for a hackathon project.
I found that if you have a complete recording of both sender and receiver (complete = starting from before first byte is sent/received), that gives you the ability to take some received byte in the receiver’s memory, and trace it back to the matching byte in sender’s memory. I think that’s pretty neat and that level of abstraction is useful in a lot of cases, without any higher level protocol knowledge.
For finding corresponding fds in processes, network sockets are relatively straightforward. UNIX sockets also aren’t hard. The awkward ones are sockets created with socketpair (and inherited with fork), and sockets that are sent via msgs on other sockets.