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

Wed Feb 6 08:21:17 PST 2008

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

------- Comment #5 from mathieu.lacage at sophia.inria.fr  2008-02-06 11:21 -------
(In reply to comment #4)

> > 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.
> 
> Not at all, the difference is not in asynchronous vs synchronous.  The
> complexity I talk about refers to having to keep track of a counter "bytes
> asked to send but not yet fully sent", and knowing a threshold, in order to be
> able to send as much data as TCP can handle without collapsing NS-3.

Keeping track of this counter should not be needed. That was my point.

> 
> In asynchronous callback based libraries, like GLib, you are notified when the
> socket buffer accepts more data, and so it's dead easy to send as much data as
> TCP can handle.

Yes. I agree that this is what you should be able to do with the ns-3 sockets.
And I agree that it is a bug that you can't do this now.

> 
> > 
> > > 
> > > 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.
> 
> What makes you so _sure_ this is what is best.  BSD sockets have been around
> for decades; they do not work as you describe, and they seem to have worked
> fine all this time.  I honestly don't see any reason why it is simpler to
> notify that data has been sent than to notify that there is room in the send
> buffer for more data.

I actually proposed that you are notified when data is removed from the tx
buffer after it was acked, that is, when there is room in the tx buffer. So, it
seems that we agree.

> 
> In fact, what applications usually want to know is that there is room in the
> buffer, not that the last data was acknowledged.  If you wait for ack's,
> especially with large delay networks, the application then has to take some
> time to produce more data, and meanwhile the TCP socket will have no data to
> send and will just sit there idle, and network will end up being underutilized.

yes, again, we agree.

> 
> 
> 
> > 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.
> 
> It actually works for _my_ case, but NS-3 sockets are not reallistic and one
> year from now a new issue will come up because we chose to deviate from the
> standard interface for no apparent benefit.

I do not think that this is true, that is, that we are deviating in the
interface. It seems that there is a bug in the implementation though and yes,
we should fix it.

> I am fine with keeping two different callbacks, though.

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