[Click] Again a beginner question

Beyers Cronje bcronje at gmail.com
Thu May 24 20:07:33 EDT 2007


Hi,

The following response is my personal experiences and opinions as a happy
Click user :)

i have similar problem as rest of the beginners, the problem is that CLICK
> have evolved so much that for a starter it gives a huge setback when u
> look
> at the amount of code written.


First off I would recommend that anyone who wants to start off using Click
must have some basic network knowledge, ie OSI Layers, IP Addressing,
subnetting, routing, TCP/UDP etc. Without this I think you'll have a hard
time using Click.

Before you even start looking at the code you need to understand Click's
architecture and how Click packet processing works. Eddie's thesis document
http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf does a great
job of this without even touching on any code at all. Once you have a basic
understanding of the architecture and packet passing through elements you
can start to play with small Click configs, ie

FromDevice(eth0) -> Counter -> Discard;

Understand how packets are pushed or pulled from one element to the next.
I.e. a simple config to receive packets on eth0 and transmitting them out on
eth1 would look like this:

FromDevice(eth0) -> Queue -> ToDevice(eth1);

The above example, packets are pushed from FromDevice to the Queue. The
Queue element is sort of like a bridge between the push and pull paths.
FromDevice pushes packes into the Queue where it's stored, while ToDevice
pulls packets from the Queue out eth1.
It's crucial to understand PUSH and PULL operation and element input and
output ports in Click. Refer to the thesis doc above for more information.

Use Print elements to visualize things. I.e:

FromDevice(eth0) -> Print(FromDevicePushToQueue) -> Queue ->
Print(ToDevicePullFromQueue) -> ToDevice(eth1);
or
tee :: Tee(2);
FromDevice(eth0) -> tee;
tee[0] -> Print(FirstCopy) -> Discard;
tee[1] -> Print(SecondCopy) -> Discard;

Only after you understand basic Click operation I would recommend looking at
the code. Personally some of the beauty of Click is the modularity. It
enables you to break things down in small isolated elements. In other words
there is no need to look at ALL of the code written for the entire Click
distribution to start learning. Start small, look at the Discard, Tee,
Counter etc elements. Look at the basic functions required for an element -
Configure(), Push()/Pull()/Simple_Action() etc.
Write a simple element that prints out the Source IP address of a packet
using click_chatter() and grow from there.

I have been trying to study  a project which uses click framework, and for
> that testing purpose i tried to use the debugger mode, and it was amazing
> at
> the way the command was being shifted to so many files, ( which btw i
> didnt
> get much)


Stay away from a debugger if you want to learn a framework. You'll see A LOT
of jumping around in any reasonable size software project, especially so for
C++ or any OOP project. Debuggers are meant for debugging...
Rather isolate a specific element in your project and use click_chatter with
lots of output, or if you have to use a debugger make use of the build in
Step-Over/Into/Out etc features.

FromDump is also a good tool. Use ethereal or Wireshark to capture packets.
Then use FromDump to 'replay' the captured packets into a Click config. This
way you are assured that everytime all packets will be controlled and the
same.

i just want to ask if anyone has ever transferred a bitmap or .wav or any
> video file using click? i found one file in the element/userlevel/ folder
> names fromfile.hh fromfile.c , but amazingly it hasn't been derived from
> element class, there was no documentation available for it on the click
> website which clearly shows that it was not the original click file.


Click is a Packet Processing Engine and NOT a transport protocol or protocol
stack. You can do a lot of things with Click, even implement a protocol
stack yourself, but it remains a packet processing engine. User FromDump
instead for your purposes.
Also remember, the very first question in the Click FAQ document is
surprisingly:

Is Click experimental software? Yes.

In other words I'm sure FromFile has/had some experimental use at some stage
:)


i tried looking into the fromdevice and ratedsource elements but couldn't
> find much help in them either.


FromDevice, PollDevice, RatedSource etc are some of the more complex
elements. They sit at the start of the PUSH path and implement more advanced
features of Click such as Tasks and Timers.

as from the previous mails i find that not much help is being offered to
> people who are not that good at programming, as this group is meant for
> the
> testers of click, but if someone does reply and help me out , it would be
> very kind of him/her.


Why dont you post specific questions regarding the project you are studying.
What does the project do? Post some example click config files or code
segments you dont understand. Note though that my personal interests and
research is more focused on TCP/IP and Ethernet, so dont expect much input
from myself on Wireless networking with Click :)

i hope by doing this small experiement with someone's help i would be able
> to understand the working of CLICK and so would help me alot in working on
> it for future.


I hope this helped a bit. Once you get the basics right you'll see Click is
a breeze.


Beyers


More information about the click mailing list