Bug 1274 - Patches to TCP
Patches to TCP
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: tcp
pre-release
All All
: P5 normal
Assigned To: Adrian S.-W. Tam
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 12:53 EDT by Adrian S.-W. Tam
Modified: 2011-12-10 21:30 EST (History)
2 users (show)

See Also:


Attachments
Patch to tcp-socket-base.cc and tcp-socket-base.h (9.93 KB, application/octet-stream)
2011-09-29 12:53 EDT, Adrian S.-W. Tam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian S.-W. Tam 2011-09-29 12:53:47 EDT
Created attachment 1250 [details]
Patch to tcp-socket-base.cc and tcp-socket-base.h

The current TCP implementation (TcpSocketBase) has some minor problems, which causing several bugs filed (e.g. bug 1227). This patch closes several problems found, listed below:

1. Make connection count (m_cnCount) a separate variable than the number of connection retries (m_cnRetries), so that the number of connection retries can be cloned without affecting the number of connections to be made in the cloned sockets

2. Instead of ignoring the out-of-order packets (i.e. seq number < expected), now sending an ACK for each received to catch the case that the peer may have lost the ACK. This closes bug 1227.

3. There was a case that the m_highTxMark was mistaken as m_nextTxSequence

4. The endpoint allocation/deallocation is rewritten so that the endpoint now remembers the correct peer's address. So the RecvFrom() call can use the data in endpoint to return the peer's address

5. The socket was not closed nicely as the endpoint is not released upon close. Now fixed.

6. TCP can now move from TIME_WAIT state to CLOSED state after 2*MSL, i.e. 4 minutes. Because of this, a new event is created upon moving to TIME_WAIT state.

7. Added Raj's email to the preamble, as TcpSocketBase was modified from TcpSocketImpl.
Comment 1 Tommaso Pecorella 2011-11-17 21:41:42 EST
I have no issues with the patch, just one question.

In case of normal (cumulative) ACKs (i.e., not SACK) a lost ACK is superseded by the following ones, that are including the missing ones.
Well, this is at least what the "plain" TCP ACK should do.

So I guess that the correct behavior is not obtained by patching the receiver, but the sender. The case of SACK is kinda different of course, and a bit more complex.

Mind, it's 3:40 am here, so I'll check the code, but not tonight.