hi Martin, this question has been asked several times in the past, and here are links to some discussions from the past: http://sourceforge.net/p/simple-evcorr/mailman/simple-evcorr-users/?viewmonth=200903&viewday=31 http://sourceforge.net/p/simple-evcorr/mailman/simple-evcorr-users/?viewmonth=201205&viewday=8
Using log file timestamps for implementing an artificial clock involves a number of non-trivial issues. Since sec rules (e.g., Calendar), event correlation operations (e.g., PairWithWindow), actions and contexts can create additional input events for sec, the system clock can not merely be adjusted in steps defined by log file timestamps. For example, if two consecutive events have timestamps 30 minutes apart, there could potentially be many contexts and event correlation operations which time out during these 30 minutes, and could potentially produce new input for sec. This means that if clock is shifted forward by 30 minutes, all these input events would be skipped. If one implements an artificial clock which ticks with increments of 1, the sec code would still require considerable changes, such as delaying the reading of available input data since it actually comes from the future. One thing which would still be difficult to handle are external actions which produce input for sec (like 'spawn' and 'cspawn') or influence sec in other ways. Suppose sec executes a 'spawn' action which runs for 10 seconds in real time, and then produces an input event for sec. Since the artificial clock ticks much faster, the input event might arrive 10 hours later for sec. If there is a PairWithWindow rule which processes that event, it will fail to work properly. Things would get even more complex if one wants to process events in real-time (provided their timestamps match the readings of the system clock), but also take into account events with their original timestamps if they arrive with a delay. For example, if there is a PairWithWindow rule for correlating events A and B, and action has been already executed for scenario "A not followed by B in 10 seconds", the late arrival of B would involve retracting the executed action. In short, processing past events is not so easy and a lot depends on how exactly time is modeled. What is certain, though, is that the sec code would need considerable modifications, and a number of its features are likely to not function properly with artificial time. kind regards, risto 2015-11-04 17:50 GMT+02:00 <mar...@brett.com>: > > > I am trying to process logs historically as opposed to in realtime and I > would like to set time expiry for rules and contexts based on time > information held in the log files as opposed to the realtime clock at time > of processing, is there a method for doing this? > > if not could this considered as a future enhancement? > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > >
------------------------------------------------------------------------------
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
