Re: [Pandora] Component::notify()

[uaca]

On Thu, Dec 05, 2002 at 07:17:12PM +0100, Simon Patarin wrote:
> 
> 
> > Hi (all?)

[...]
> You feel a little bit lonely, don't you? I have warned you! :)

I didn't understand the joke :-(

> > What happens if @mycomponent just wants few packets?
> 
> He's in trouble (but may I ask why do you need it in the first place?)

of course, but don't tell anybody :-) 

first I want to measure the RTT using the 3WHS

[...]
> > we are no longer interested in this TCP flow!
> 
> I agree that there is some sort of a problem here. The only case where I
> have faced the same kind of problems is when you receive 3 or more TCP
> resets in a row. You understand that the connection is finished as soon as
> you receive the first one, so I used to clean the branch, but each
> following reset triggers the creation (and the immediate destruction) of a
> new branch. 

ok, I understand this

> 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?

but it would still receive packets... ¿?

in the other hand in ::add() it calls reschedule(2) 

that means it will not accept new packets within 2 seconds?



> > my propossal:
> > 
> > add to the Packet class a new virtual method (name it ::accept()) so 
> > DemuxComponent::add() in this case would be something like:
> [...]
> > 
> >       if (!pkt->accept()) {        <<< Here
> >     cleanPacket(pkt);          <<< Here
> >     return false;              <<< Here
> >       }                            <<< Here
> [...]
> 
> I have a problem with your proposal: how do you implement the accept
> method for e.g. the TCPPacket class? how can you make it generic? how does
> the packet know that it should not be accepted? I can't figure this out.

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'm supossing there's no other method for doing this already
> 
> Unfortunately, you're right, except by maintining artificially in life
> your component (i.e. never returning true, but instead silently discarding
> superfluous packets) and relying and pandora's timeout to collect your
> component after some time of inactivity. You know the generic
> "timeout" option don't you? any component accepts it: 
> @mycomponent [$timeout = 30] means that if no packets are forwarded to
> this component during 30 seconds it will be automatically cleaned up.
> The timeout is reset each time a packet is received, if you want it to be
> absolute, you just need to specify $resched = false, in this case the
> component "lives" 30 seconds at max. 

I could test if it works for me

> > Why do I think this should be this way? 
> > 
> > _because kmap is in the demux component_
> 
> Yes, there are no other places to do it. However, I'd be more inclined to
> make another component, let's say "demuxonce" that is a clone of demux
> except for a few things: in notify, instead of removing completely the
> branch, I'll replace:
> 
>   if (b < 0) kmap.removeVal(b);
> 
> by 
> 
>   if (b < 0) kmap.atPut(kmap.keyAt(b), -b);
> -b is not a valid branch value (it must be strictly negative and 0 is the
> default value -- when no branch exists), so you can detect it in the
> add() method just after:
> 
> if (b == 0)
> {
>   ...
> }
> 
> you can add:
> 
> else if (b > 0) {
>   cleanPacket(pkt);
>   return false;
> }

very nice, much beautiful than my proposal

> The final issue is to remove the assertion in the destructor because the
> size will not be 0 anymore, however you do not have to worry about
> deleting data in the map: it is automatically allocated.
> If you do not want to make a new component, I'm sure that this could be
> controlled with an option, well, actually this would be much better with
> an option! The last problem is to know how much time you want the branch
> to be "fobidden". 
> Here it is forever, if you want to make it a paramater
> it becomes a little bit trickier: you have to remove the marked branch in
> the map (with kmap.removeVal) after some specified amount of time. You can
> look at the sched_manager class (in libpandora) and the testcomponents.cc
> file (in pandora_components) to have an idea on how this could be done.

Ok, I've got the picture, that's like a garbage collector :-)

so If the timeout is too less than so the upstream component is not
interested with new packets of that kind then it will again indicate 
that to the multiplexor for another period, reasonable


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


        Ulisses

                Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers."            Pablo Picasso

--->    Visita http://www.valux.org/ para saber acerca de la    <---
--->    Asociación Valenciana de Usuarios de Linux              <---