[Bro] tcp contents
john mcnicholas
jomcn at mail.com
Tue Nov 30 04:21:05 PST 2004
> Is there some reason why you want to have both directions in a single
file?
The initial reason was twofold: just to reduce the number of files and to be
compatible with a prototype that had been developed. Clearly neither are
critical and if the 2 file approach is faster/efficient then that should be
enough to trump the single file approach given the importance of speed.
> Ah - I realized the key problem, which is that CONTENTS_BOTH is not in
> fact a valid parameter for set_contents_file. The way that contents are
> extracted from streams, it simply can't work. (The definition is lying
> around because it's used internal to the event engine in a slightly
> different context.)
I really don't want anyone spending more time on this but:
a. do you think I just didn't look hard enough at the data for a single file
(i.e., it wasn't working when I thought it was)
or
b. the single file approach would work "most of the time" or all of the time
if a connection (such as HTTP_Conn or SMTP_Conn) added a contents processor
derived from TCP_ContentLine. i.e. it would work if the TCP_Connection's
BuildEndpoints() method did something functionally equivalent to:
orig->AddContentsProcessor( new TCP_ContentLine(orig,1,0,1));
resp->AddContentsProcessor( new TCP_ContentLine(resp,0,0,1));
Obviously "most of the time" isn't good enough but it would explain why a
cursory check of the output looked valid.
Once again even if the single file did work, if the 2 file approach has a
measurable speed advantage we'll probably make the necessary changes to our
protocol handlers/applications.
Thanks again for your time and help.
John
More information about the Bro
mailing list