[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