[Ns-bugs] [Bug 131] Sending data in the TCP send callback causes infinite recursion

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=131





------- Comment #2 from gjcarneiro at gmail.com  2008-02-06 10:13 -------
(In reply to comment #1)
> If you'd like to send TCP data "as fast as possible" you just need write all of
> the data into the socket, all at once.  Since flow and congestion control are
> implemented, the socket will buffer the data you write to the socket, and will
> send it appropriately according to its flow/congestion algorithms.  See
> examples/tcp-large-transfer.cc 
> 
> It seems to me that that if you wanted to send data one chunk at a time with
> your approach, that it should be up to your code to check to see if you are out
> of data, and if so, don't call Send.  Doesn't this break the loop of which you
> speak?
> 
>     Quote:I would expect TCP to eventually stop calling me
>     to send more data, for some time...
> 
> To clarify some about the implementation, the registered callback gets called
> whenever data is actually sent down the stack...the semantics are more like a
> notification of sent data, not necessarily a request for more data.

*sigh* I _really_ think we are deviating too much already from the BSD sockets
interface.  Because we are "simplifying" we end up with completely different
socket semantics, and the new semantics are not as well tested in real world as
the old ones.

To clarify, what I want to do is to send as much data as possible.  There is no
limit to the data to send, I just want to saturate the network with TCP
traffic.  In plain old C sockets I would do something like:

int s = socket(...) # create and connec the TCP socket
struct pollfd fds[1] = {{s, POLLOUT, 0}};
while (1)
{
  poll(fds, 1, -1);
  if (fds.revents & POLLOUT) {
     send(s, buf, SIZE, 0);
  }
}

This code will send as much traffic as possible, with implicit flow control. 
The poll() is used just to illustrate that this could as easily become
asynchronous, callback-based just like NS-3, with little additional complexity.

>From what you say, to do this in NS-3 I'd have to keep track of the number of
bytes "in transit", and send more data only when the number of bytes in transit
is below a certain threshold.  Conclusion:
1. I have to keep track of in transit bytes;
2. I have to _know_ which threshold is adequate before deciding to send more
data;

Clearly the NS-3 solution is an order of magnitude more complicated than real
life!


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.