On Oct 12, 2012, at 4:00 PM, James Swaro <[email protected]> wrote:
> As I am aware, Bro has steadily moved toward a multi-threaded approach to > logging at the least. For an analyzer that I've been developing as part of my > research, I am curious to know if network_time remains coherent with the > network time given in pcap files and live capture. If not, is there a more > accurate variable available? There are several things going into this from what I understand. network_time is obviously driven by the packet timestamps so it's going to represent the most recent packet received. Do to stream reassembly and it's interaction with the event queue it's possible that there are misrepresentations in the value returned from network_time(). If you use current_time(), that's going to get the current clock time but that could also be misleading due to latency in the event queue. The best answer I have is like most things in Bro, you have to transition your mind away from packets and if what you are trying to do is intrinsically some packet level thing Bro might not be the right too (unless you are working in the core where you can absolutely do packet level work). On the upside, Bro does flush it's event queue after every single packet so it's not like you are going to see large latency due to the event queue. Bro's event queue and stream parsing were not threaded either. Only the logging and input frameworks which almost certainly won't affect anything you are doing. .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
