[Click] How to handle multiple flows?

[Harald Schiöberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Beyers Cronje wrote:
> 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.

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...)
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.
- - calling a handler would be doen once per packet. I have no clue about
performance of handler calls.
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)


otherwise this sounds like a proper alternative.

cheers
	harald



> 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:
> 
> 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 ))
> 
> 
>>
_______________________________________________
click mailing list
click at amsterdam.lcs.mit.edu
https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>

- --
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

iD8DBQFIc+l+Jgyxs71kcx4RAkgVAKDLRsGNWRRlrOIjn0rB9W2S50VDtwCdHPtB
/sHas6msBLI0enIOlmezMhc=
=MGlw
-----END PGP SIGNATURE-----