[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 #4 from gjcarneiro at gmail.com  2008-02-06 11:11 -------
(In reply to comment #3)
> > *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.

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.

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.

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

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.



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