{"id":719,"date":"2017-12-08T10:42:51","date_gmt":"2017-12-08T10:42:51","guid":{"rendered":"https:\/\/projects.lsv.ens-paris-saclay.fr\/orchidsdoc\/?page_id=719"},"modified":"2017-12-08T10:42:51","modified_gmt":"2017-12-08T10:42:51","slug":"monotonicity","status":"publish","type":"page","link":"https:\/\/projects.lsv.ens-paris-saclay.fr\/orchidsdoc\/?page_id=719","title":{"rendered":"Monotonicity"},"content":{"rendered":"

The events that Orchids receives and dissects are composed of fields. \u00a0In addition to a type<\/a>, each field has a monotonicity<\/em> status.<\/p>\n

In each module page, we write\u00a0\u2713 in the `mono?’ column for fields that are\u00a0monotonic<\/em>. \u00a0Those are fields that can only increase (or stay the same), as new events occur. \u00a0The typical monotonic field is a time stamp or a sequence number.<\/p>\n

The purpose of monotonicity<\/h3>\n

The monotonicity flag is used by Orchids to make a few important optimizations. \u00a0Some of them are described on the timeout<\/code><\/a> module page. \u00a0If you write something like this in an Orchids rule:
\nexpect (<\/code>\u27e8what I am waiting for\u27e9 &&\u00a0<\/code>\u27e8my time field\u27e9<$timeout) goto<\/code>\u27e8wherever\u27e9;<\/code><\/p>\n

where $timeout<\/code> holds the final time after which we will no longer care whether\u00a0\u27e8what I am waiting for\u27e9 happened or not, and\u00a0\u27e8my time field\u27e9 is flagged as a monotonic field, then Orchids will\u00a0stop waiting after receiving the first event whose\u00a0\u27e8my time field\u27e9 field is larger than or equal to $timeout<\/code>. \u00a0The way the Orchids compiler reasons is as follows: imagine Orchids receives an event whose\u00a0\u27e8my time field\u27e9 value is larger\u00a0than or equal to $timeout<\/code>; then any event it will read later will have an even larger\u00a0\u27e8my time field\u27e9, and the condition of the expect<\/code> transition will be false forever<\/em>. \u00a0Hence it makes no sense monitoring that condition, and we can kill the corresponding thread.<\/p>\n

A matter of trust<\/h3>\n

Orchids trusts<\/em> that monotonic fields indeed only increase, but some event sources may contradict that assumption.<\/p>\n

If you see a monotonic field decrease, that may be the result of malevolent conduct. \u00a0That may happen in natural situations as well. \u00a0For example, if\u00a0\u27e8my time field\u27e9 reports times relative to a local time zone, and the time goes suddenly back from 3am to 2am in the middle of the night, it may be an effect of exiting daylight saving time<\/a>. \u00a0The ideal cure is to have a time reporting mechanism that reports absolute values of time, not depending on a time zone or on daylight saving time, for example a Unix time count (numbers of seconds since a fixed date), or expressive and normalized time fields such as in RFC5424 syslog<\/a>.<\/p>\n

Beyond<\/h3>\n

In principle, fields can also be flagged as antitonic (decreasing or staying the same), or constant (staying the same). \u00a0This is needed by the logic that Orchids uses to reason about monotonicity. \u00a0At the moment, no field is flagged as such.<\/p>\n

Monotonicity does not make sense for data of all types. \u00a0The order that Orchids uses is:<\/p>\n