[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 #3 from mathieu.lacage at sophia.inria.fr  2008-02-06 10:54 -------
> *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.

The semantics are different because our API is an _asynchronous_ API, that is
all. All the complexity you refer to comes from this. What you seem to be
confused by is that you want a _synchronous_ API and yes, this is desirable but
it is not there yet.

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

Sure, however, to implement this, you would need a thread library to implement
the blocking poll call and, so far, this has not been done.

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

No, what is missing is a way for a user of a Socket object to be notified when
there is room available in the tx buffer. More about this below.


(In reply to comment #1)

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

The semantics _I_ expect are that it (the sent callback) should be invoked when
the associated data has been _completely_ sent and acked for TCP. i.e., when it
has been removed from the tx buffer. At this point, I believe that it is
perfectly legitimate to attempt to send more data from this callback and to
expect the system not to crash on you. i.e., what gustavo is trying to do seems
perfectly legitimate.


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