[Click] How to handle multiple flows?

[Beyers Cronje]

Hi Harald,



> Two questions:
> - - is calling a handler and later pulling a packet guaranteed to be
> atomic? I only need single-threaded click, so I personally don't mind if
> it's not thread save. (perhaps someone else does...)


If you want to make it thread safe you would need to look at protecting your
flow packet buffers etc as both TCPSpeaker elements could be running in
seperate threads.


>
> But I don't know at which points arriving packets are able to break
> atomicity of the control flow between elements even in single thread click.


In multithreaded click any queue type element with a Push and Pull port
could potentially be used by seperate threads. In single threaded click this
will never be an issue as there is only one thread.


>
> - - calling a handler would be doen once per packet. I have no clue about
> performance of handler calls.


Anyone correct me if I' wrong, calling a handler from another element is
purely an object method call. It is different than calling a handler through
Click's proclike fs or ControlSocket.


>
> this whole thing is targeted to embedded wireless routers, I rewrote a
> lot of code to restrict it to zero packet copy incoming and one copy
> outgoing (keep a copy for retransmissions)


Can you possibly give an example of how or why you would use this? I've done
some nifty TCP features in Click in the past like Snoop TCP and Indirect TCP
so it would be nice to get an idea of what the application of this feature
would be?

Beyers