[Click] PokeUnqueue

[Bart Braem]

Hi Eddie,

Our students tested the current element and they think they discovered  
that unqueue(BURST 1) always passes all packet, without the need for  
calling Script(unqueue.reset) ... They tested with

ICMPPingSource(143.129.67.91, 143.129.70.2, LIMIT 5)
     -> Queue
     -> Unqueue(BURST 1)
     -> IPPrint("ping")
     -> Discard;

This prints ping 5 times, even when no reset handler is called.

We are looking for this functionality to be able to inject only 1  
packet in the network. We would read packets from a dump and put them  
in a queue. Then we would have one packet processed and then query the  
statistics from Counter elements etc., then inject the next packet and  
so on. To avoid having to split up a dump of 100 packets in 100 dumps  
of one packet and 100 different scripts, we wrote the PokeUnqueue  
element.

Perhaps PokePull would have been a better name, we want to be able to  
poke an element and have it pull 1 or more packets.

Should this be a separate element? I think it might be a good idea,  
but I am not sure. Other elements with pull outputs might also be used  
in similar scenarios.

Regards,
Bart

On 26 Mar 2009, at 18:29, Eddie Kohler wrote:

> Hi Bart, Jens, Nico,
>
> Thanks for this element!  I wonder, though, whether it would be  
> better to update Unqueue to support this functionality.  I've  
> checked in to Unqueue a new arugment, LIMIT, and new handlers,  
> reset, limit, and burst.  The equivalent of PokeUnqueue.poke would  
> be something like
>
> ... Unqueue(BURST 4) ...
>
> Script(write uq.reset)
>
> -- but not quite, since the Unqueue will reschedule itslef until 4  
> packets are pulled, and PokeUnqueue would pull at most 4 packets in  
> one go.  I wonder what  you are using PokeUnqueue for, whether you  
> think it's important to have a separate element, etc.
>
> Eddie
>
>
> Bart Braem wrote:
>> And once again attachments sent over our mailserver do not find  
>> their way to the mailinglist, strange.
>> Hopefully now they do.
>> Sorry for the noise,
>> Bart
>> On 12 Mar 2009, at 16:17, Bart Braem wrote:
>>> Eddie,
>>>
>>> Attached you will find a very basic element that will unqueue BURST
>>> packets if poked, default 1. We use it behind a queue to unblock  
>>> BURST
>>> packets on a specific moment, triggered by a write handler. Similar
>>> functionality seemed not available in other elements so this looked
>>> like a good addition. We did not find a better name, feel free to
>>> adapt it if needed.
>>> Credit for writing the element goes to Jens and Nico, in CC. I have
>>> done a basic functionality test, together with a valgrind check. If
>>> anything more is needed, feel free to contact me. Otherwise, we  
>>> would
>>> be happy to contribute this to the project.
>>>
>>> Regards,
>>> Bart
>>> -- 
>>> Bart Braem
>>> PATS research group - IBBT
>>> Dept. of Mathematics and Computer Sciences
>>> University of Antwerp
>>> Campus Middelheim, G3.30
>>> Middelheimlaan 1
>>> B-2020 Antwerpen, Belgium
>>> Phone: +32 (0)3 265.32.91
>>> Fax: +32 (0)3 265.37.77
>>> Web: www.pats.ua.ac.be
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> ------------------------------------------------------------------------
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click