On Tue, 2010-11-23 at 21:36 +0100, manel.bourgu...@lip6.fr wrote: > Thanks for your answers. > I had a look at the thesis that proposed TCPSpeaker. It seems > interesting to use this element. But the only example given is in the > case of a proxy. My need is much simpler: two hosts: one source and > one sink communicating with TCP. > So how to generate the flow in the source and send it to the sink? > let's say with RatedSource, can I have (in the source) roughly > something like : > RatedSource (...) -> [0]TCPSpeaker > TCPSpeaker[0] -> ToDevice(eth0) > FromDevice (eth0) -> [1]TCPSpeaker > TCPSpeaker[1] -> ToDevice(eth0) > > Actually, I didn't understand the utility of having two output and two > inmput ports.
because TCP establishes bi-directional connections, while click ports are uni-directional so you need pairs. You cannot separate the directions into 2 Elements, since ACKs and data is transported on the same packet for the different directions. If you only need unidirectional transport, connect the remaining ports to Idle/Discard. Your example is exactly right, just make sure that TCPSpeaker gets valid TCP/IP or UDP/IP encapsulated packets. No need to worry about seq &co, just the IP Address and Port fields must be filled correctly, so that TCPSpeaker can associate it with a connection. TCPSpeaker accepts either TCP or UDP Packets, but will always emit TCP packets. There is some doxygen in the sources, but I'm not too proud of it :( Dan wrote a Master Thesis using and profiling the code, here it is: http://www.net.t-labs.tu-berlin.de/papers/L-TCMWMN-10.pdf It's probably the best documentation that is available. Hope that helps. Harald _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
