On Mar 13, 2014, at 2:55 PM, Bernhard Amann <[email protected]> wrote:
>> >>> …even after reading through the how to, I was not quite clear on the fact, >>> that get_file_handle >>> has to always return the same value for the same file. Which is impossible >>> to accomplish in cases >>> like this, because, several certificates are sent over a connection, and >>> you do not get any further information >>> with the get_file_handle call. So - you more or less have to return >>> differing IDs for everything. >> >> Instead of incrementing the depth in get_file_handle, it could increment it >> in a x509_certificate handler? That way the handle remains the same between >> the DataIn/EndOfFile pairs, but the next DataIn/EndOfFile will get a new >> file handle due to the incremented depth. >> >> Not suggesting you change it from using the pre-computed file id method you >> currently have, just challenging the impossibility claim :). And I do agree >> the whole script-layer generation of file handle string is difficult to >> understand/use, but I don’t have any ideas at the moment for helping that... > > That might work, yes… but.. > > If I do several DataIn -> EndOfFile -> DataIn -> EndOfFile calls in rapid > succession (without anything in-between), as I am doing at the moment, is is > guaranteed that the events that are raised by the FaF in an EndOfFile call > are processed by scriptland before the (directly following) next DataIn call? If you are using a pre-computed file-id, then no. If you aren’t, then yes, it flushes the event queue every time it needs to call out to the script-layer in order to generate a file-id. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
