[PATCH v2 1/1]

After further experiments I am resubmitting this patch, using a higher RTT estimate for the Close/CloseReq retransmission timer. The problem with the fallback RTT of 200ms is that it is lower than several link types. I have experimented on (emulated) satellite links which have an RTT of ~600ms.

Re: Passive-close patches

After further analysis, I think that the way passive-close was implemented by the patches (using intermediate states) is the cleanest (and maybe the simplest solution). It would be nice if it worked with the present approach of just enqueueing via dccp_fin, but several demands make a simple sol

Re: TX history patches was: Re: Test tree patch inventory - update

| > Also did you test this code? The patch on which this is based has been | > subjected to some extensive regression-testing. I can't tell if it will | > perform as intended. | | I performed testing, not exhaustive as the code should be equivalent to | what you had done, or can you find, from cod

Re: [PATCH 06/18] [DCCP]: Initialize dccp_sock before calling the ccid constructors

| This is because in the next patch CCID2 will assume that dccps_mss_cache is | non-zero. | Good catch - in the test tree this problem didn't occur since the CCIDs are initialised after everything else has been done (i.e. only after the handshake has completed, which is much later than init_sock()