Re: [Pandora] Component::notify()

[Simon Patarin]

> > You feel a little bit lonely, don't you? I have warned you! :)
> 
> I didn't understand the joke :-(

This was just to say that there were not too many people on this list!

> first I want to measure the RTT using the 3WHS

I suppose that you know this paper:
http://www.ieee-infocom.org/2002/papers/678.pdf
I have always been conviced that similar results could be easily obtained
with pandora, I hope that you will manage to confirm it.

> > That was annoying, so instead of cleaning the branch
> > immediately I just reset the timeout value for the branch to a very low
> > value (2 seconds), you can see this in the TCPPortDemux component.
> 
> I think I don't understand this one
> 
> IMHO: a timeout T for a component means that if this component doesn't
> receive a packet within T then remove it. isn't it?

right

> but it would still receive packets... ¿?

also right, but they ignore them (if these are indeed resets)

> in the other hand in ::add() it calls reschedule(2) 
> 
> that means it will not accept new packets within 2 seconds?

no, just that if no other packets (after the reset) are received within 2
seconds, then the component is cleaned up, which is better than having to
wait 30 seconds or have 3 components created for nothing.
 
> well that depends on how much framework you want to add
> 
> my first idea is that usually a packet just will want one accept method for
> all situations, I missed your's
> 
> It could be done like component options, in this case
> 
> tcp [ $reset=true, $syn=false ]
> 
> should not be difficult
> 
> I don't know if it must to be difficult to do it in a per stack basis
> and if that will be a code bloat, maybe too much generalization, this las
> bit

I think I understand your point better but it looks rather hard to
implement in a generic fashion.

> what do you feel more useful the ::accept() method or the key based?
> 
> I think that
> 
> + the accept method is more generic, and promises the heaven
> 
> + the key based is simpler and efective for the examples here we presented

Actually, I do not think that I'll have the time to code myself for any of
the method and I really think that the first one requires huge work and
will not fit easily in the current framework (I had never thought of
"packet" options and pretty much everything would have to be touched to
insert it).

However, do you need the other (non SYN) packets elsewhere in the
stack? If this is not the case, my own way of doing it would be to put a
"tcpsynfilter" component that discards any non SYN packets just _before_
the demux so your stack would look like this:

@pcap @tcpscan [$reject = false] @tcpsynfilter @demux [$algo = "tcpcnx"] <
        @mycomponent > @whatever

I can let you make the tcpsynfilter component if you feel like it, but it
would take me less time than writing this mail if you want me to do it!

Simon