[Click] How to handle multiple flows?

[Beyers Cronje]

Hi Harald,

If I understand you correctly the following might be a possible alternative.

First off Click already provides functionality to identify/mark flows, see
AggregateIPFlows http://read.cs.ucla.edu/click/elements/aggregateipflows
AggregateIPFlow sets the aggregate packet annotation and provides
notification features to AggregateListeners elements when aggregates are
created/deleted. With this you can develope seperate elements that share
flow identification.

Regarding your other issue, you could (and maybe should) use handlers. The
pulling TCPSpeaker can make a handler call to the other TCPSpeaker
specifying the flow identifier before actually pulling the packet. This way
the second TCPSpeaker element will know what flow the puller TCPSpeaker is
interested in.

Hope that makes sense.

Beyers


On Tue, Jul 8, 2008 at 6:12 PM, Harald Schiöberg <
harald at net.t-labs.tu-berlin.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi again,
>
> since I write that tcp thingy, here is my first problem:
>
> Say you'd like to bridge between transport protocols, such as in a
> tcp-split-proxy, the setup would look like this:
>
> connection1                       connection2
> |                                 |
> - -> |0         1| -> |1         0| ->
>   | TCPSpeaker|    | TCPSpeaker|
> <- |0         1| <- |1         0| <-
>              stateless
>              packets
>
> Both TCPSpeaker should be able to deal with multiple connections.
>
> How to design the stateless ports "1" ?
>
> Push: means if connection is choked due to congestion/flow control you
> overwhelm the port.
> Pull: If you have one connection that is chocked, and anotherone that is
> idle, you'd like to pull packets for the idle connection only.
>
> Solution would be to make ports "1" of type "qualified pull", with a
> function like:
>  Element::pull(port, thunk)
>
> so that the elements could pass each other the connection identifier.
> Since choked flows are never pulled, the windows on the upstream
> connection shrinks, and everything is fine.
>
> Has a
>  virtual Element::pull(port,thunk){pull(port);}
> any chance to make it into click?
>
> How to implement that? Something deep in click, where elements are
> connected during startup must learn about that. Where to start looking?
>
>
> Another thing:
> thunk could be a void pointer. But: it could as well be a more specific
> thing like a flow classifier. In this case more elements could start
> doing things on a per flow basis. I don't know whether that is actually
> needed. I can imagine a flow-classifier like:
>
> {
>  bitfield significant-fields
>  in_addr source
>  char    source-netmask
>  in_addr dest
>  char    dst-netmask
>  char    proto
>  u_int16 source-port
>  u_int16 dest-port
> }
>
> with tests whether a packet belongs to a flow like
> if ( !(significant-fields | FLOW_SOURCE_ADDR) ||
>   (p->source | ~source-netmask == source ))
>
>
> - --
> Harald Schiöberg
> Technische Universität Berlin | T-Laboratories | FG INET
> www: http://www.net.t-labs.tu-berlin.de
> Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIc5HYJgyxs71kcx4RAihbAJ4nNDG39JB3QSJhjR2Pb0hQWlfvrgCfWQ9S
> hwRWNI0XFDiQKm4KXNLcwUg=
> =dYrP
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>