[Click] PokeUnqueue

Eddie Kohler kohler at cs.ucla.edu
Wed Apr 1 11:04:59 EDT 2009


Hi Bart, Nico, Jens,

You would put LIMIT 1 on the Unqueue.

    -> Unqueue(BURST 1, LIMIT 1)

This should pull 1 packet at startup, and 1 packet every 'reset' thereafter. 
But you guys were right there was a real boneheaded bug in Unqueue that I just 
fixed.  With the current code the element acts as I had intended.

Eddie


Bart Braem wrote:
> 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
> 


More information about the click mailing list