Bug 239 - tcp has no finite size rcv buffer.
: tcp has no finite size rcv buffer.
Status: RESOLVED FIXED
: ns-3
internet-stack
: ns-3-dev
: All All
: P1 normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-06-25 18:45 EDT by
Modified: 2008-09-07 20:33 EDT (History)


Attachments
rebase of ns-3-dev-bug239 + changes (20.67 KB, patch)
2008-09-05 14:19 EDT, Rajib Bhattacharjea
Details | Diff
example script that exercises the new code (10.74 KB, patch)
2008-09-05 14:30 EDT, Rajib Bhattacharjea
Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-06-25 18:45:31 EDT
i.e., m_rcvBufSize is never used.
------- Comment #1 From 2008-07-01 16:56:24 EDT -------
This was an oversight on my part.  I guess I'll assign it to myself...
------- Comment #2 From 2008-07-17 18:11:04 EDT -------
http://code.nsnam.org/raj/ns-3-dev-bug239/

Needs testing and review.
------- Comment #3 From 2008-07-21 11:50:12 EDT -------
If you have done basic testing on this code (i.e., it does not crash and seems
to work), then, please commit: it will be easier to do more testing of the code
once it lands in ns-3-dev.
------- Comment #4 From 2008-07-21 11:59:07 EDT -------
(In reply to comment #3)
> If you have done basic testing on this code (i.e., it does not crash and seems
> to work), then, please commit: it will be easier to do more testing of the code
> once it lands in ns-3-dev.
> 

It doesn't crash, but not all of the behavior seems to work.  I don't think its
ready to merge, I just wanted to push an update to the tracker to keep you all
posted.
------- Comment #5 From 2008-09-02 16:12:52 EDT -------
Bump priority so this makes ns3.2

The repo is a little stale, but it works now.  I did some unnecessary hacking,
so instead of having this show up in our history I'm going to rebase, and roll
this into one patch. 
------- Comment #6 From 2008-09-05 14:19:54 EDT -------
Created an attachment (id=241) [details]
rebase of ns-3-dev-bug239 + changes
------- Comment #7 From 2008-09-05 14:30:46 EDT -------
Created an attachment (id=242) [details]
example script that exercises the new code

Unfortunately, I hacked a new API into the packet sink to make it NOT perform
any reads until a specified time.  This show's the following behavior:

1. The receiver advertised window continues to dwindle until a read is
performed and some buffer space clears up.
2. When the sender learns there is no buffer space via a zerowindow, he goes
into the persist state of sending zerowindow probes of one byte.
3. The receiver can't buffer the 1 byte probes but ACKs anyway, and after the
read is performed and buffer space clears up, it sends a new ACK.
4. The receipt of the new ACK kicks the sender out of the persist state and it
resumes transmission of regular sized segments.  

This patch however is not recommended for merging, but is proof positive that
the code does what I think it does.

Last step is to turn this example into a unit test.
------- Comment #8 From 2008-09-07 20:33:04 EDT -------
Slightly modified patch applied, along with a unit test which exercises the new
code.
ns-3-dev
3644:5d836ab1523b