I cant understand scripts asynchronous call behavior. When I pointing 20 second in tables data type attributes “&create_expire=20sec”, I find unpredictable behavior: the table`s item removed not in 20 seconds, it can be removed after 25,30 etc seconds. As I found it is depending on how many packets in the network: if there is no packets after timer value, my timer will never expire. And when the first packet appear, the timer immediately expire (but, for example, has been more than a few hours).
I can`t understand scripts asynchronous call behavior. When I pointing 20 second in table`s data type attributes “&create_expire=20sec”, I find unpredictable behavior
Unpredictable but expected. Timers in Bro aren't "hard". They will be dispatched when Bro gets around to them, not at the exact moment the timer was scheduled to fire. The only thing you can be assured of is that it won't be dispatched prior to the time which is set.
: the table`s item removed not in 20 seconds, it can be removed after 25,30 etc seconds. As I found it is depending on how many packets in the network: if there is no packets after timer value, my timer will never expire.
By default, the notion of time in Bro is driven forward by the packet timestamps which means that timer expirations will go accordingly.
No packets == no time advancement == no timer expiration.
If remote communication is enabled, the internal time will be clock driven. I don't know offhand if that requires an actual connection or if just holding open a socket will work.
And when the first packet appear, the timer immediately expire (but, for example, has been more than a few hours).
I don't understand what you are saying here. Which timer expires immediately?
Thank you for the quick reply,
Can you understand me (at least briefly) what is the reason of "...the
notion of time in Bro is driven forward by the packet timestamps...", why
not internal clock?
As I understood the only way to change such behavior (packet timestamps
clock driven) is "If remote communication is enabled, the internal time will
be clock driven...". Can one little detail, please?
Thank you for the quick reply,
Can you understand me (at least briefly) what is the reason of "...the
notion of time in Bro is driven forward by the packet timestamps...", why
not internal clock?
I expect that it was an optimization, but you'll have to wait for a response from Robin or Vern to clarify that point.
As I understood the only way to change such behavior (packet timestamps
clock driven) is "If remote communication is enabled, the internal time will
be clock driven...". Can one little detail, please?
If you load the listen-clear.bro script, that may make Bro drive off of the clock and not packet timestamps. This is where my comment about me not knowing whether an actual connection has to take place or not applies.
> Can you understand me (at least briefly) what is the reason of "...the
> notion of time in Bro is driven forward by the packet timestamps...", why
> not internal clock?
I expect that it was an optimization, but you'll have to wait for a response from Robin or Vern to clarify that point.
Yes, because in a typical deployment environment, many packets stream in
every second, and they arrive via pcap with timestamps attached. Plus,
we haven't perceived an important benefit from having precise timers; for
typical uses (keeping tables from growing too large), imprecise timers are
generally fine.
There's actually one more aspect to this: while Bro's timers are not
precise, in typical situations they are also not *that* imprecise as
you are observing here with tables. The reason here is that table
expiration is actually done in batches: there's not a an individual
timer per element (in which case expiration would be more timely),
but one per *table*. Every time that one first, a certain number of
table elements is checked to see whether they have already
expired---which is why you're seeing expirations occuring in
discrete intervals. You can fine-tune the specifics of this process
with the parameters table_expire_interval, table_incremental_step,
and table_expire_delay; see policy/bro.init.
Timers in Bro aren't "hard". They will be dispatched when Bro gets around to them, not at the exact moment the timer was scheduled to fire. The only thing you can be assured of is that it won't be dispatched prior to the time which is set.