<font face="times new roman,serif"><font class="Apple-style-span" size="4">After checking Bro's code (especially Analyzer.h, Analyzer.cc), I think the logic is like this (please point out if I am wrong): </font><br></font><div>
<font class="Apple-style-span" face="'times new roman', serif" size="4">TCP_Analyzer will parse the TCP protocol and extract the palyload (input to application level protocol analyzer), this payload will be passed up to Analyzer class (how to pass is not clear to me). </font></div>
<div><font class="Apple-style-span" face="'times new roman', serif" size="4">After Analyzer knows this stream of TCP payload and this is the input of the ForwardStream. ForwardStream then call Analyzer's children to use their own DeliverStream. In each DeliverStream implementation, the Binpac Conn function is used to parse the stream. So in my opinion, from Analyzer, TCP_ApplicationAnalyzer to the application-level analyzer, the stream actually does not change. </font></div>
<div><font class="Apple-style-span" face="'times new roman', serif" size="4"><br></font></div><div><font class="Apple-style-span" face="'times new roman', serif" size="4">But for my situation, I have two application-level protocols, p1 and p2. p1 derive from TCP_ApplicationAnalyzer and p1 needs to parse and reconstruct stream from TCP level, not directly pass the stream to p2. So I think what I can do is to let p2 derives from p1. And then define a event handler in p1 to reconstruct stream as it parse its protocol, in this event handler, we can have the reconstructed stream and use it as the input to call ForwardStream of p1. p2 still defines the DeliverStream as usual, and in this way, p2's protocol analyzer should be able get those reconstructed stream. </font></div>
<div><font class="Apple-style-span" face="'times new roman', serif" size="4"><br></font></div><div><font class="Apple-style-span" face="'times new roman', serif" size="4">Best,</font></div><div><font class="Apple-style-span" face="'times new roman', serif" size="4"><br>
</font><div class="gmail_quote">On Mon, Aug 8, 2011 at 8:49 AM, Robin Sommer <span dir="ltr"><<a href="mailto:robin@icir.org">robin@icir.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Sun, Aug 07, 2011 at 21:56 -0700, you wrote:<br>
<br>
> So it seems that TCP_ApplicationAnalyzer behave like a helping interface<br>
> between TCP protocol and other application-over-TCP protocol. I would also<br>
> like to learn how TCP_Analyzer passes payload to TCP_AppliationAnalyzer in<br>
> implementation. For the DNP3 protocol, I actually have to write two<br>
> application level analyzer and one passes the payload to the other one to do<br>
> some further parsing. I would like to refer TCP's implementation.<br>
<br>
</div>TCP's data flow is more complex than you need (I believe) because the<br>
TCP reassembler is potentially involved too. In your case, the first<br>
analyzer would call its ForwardStream(), and the data will then show<br>
up in the second's DeliverStream() method.<br>
<div><div></div><div class="h5"><br>
Robin<br>
<br>
--<br>
Robin Sommer * Phone <a href="tel:%2B1%20%28510%29%20722-6541" value="+15107226541">+1 (510) 722-6541</a> * <a href="mailto:robin@icir.org">robin@icir.org</a><br>
ICSI/LBNL * Fax <a href="tel:%2B1%20%28510%29%20666-2956" value="+15106662956">+1 (510) 666-2956</a> * <a href="http://www.icir.org" target="_blank">www.icir.org</a><br>
</div></div></blockquote></div><br></div><br clear="all"><br>-- <br>Hui Lin<br>Research Assistant<br>DEPEND Research Group, ECE Department<br>University of Illinois at Urbana-Champaign<br><a href="mailto:hlin33@illinois.edu" target="_blank">hlin33@illinois.edu</a><br>