/* <pre>
* 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)
*
* This usually indicates an initialization collision, i.e., each
* endpoint is attempting, at about the same time, to establish an
* association with the other endpoint.
*
* Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
* respond with an INIT ACK using the same parameters it sent in its
* original INIT chunk (including its Initiate Tag, unchanged). When
* responding, the endpoint MUST send the INIT ACK back to the same
* address that the original INIT (sent by this endpoint) was sent.
*
* Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
* respond with an INIT ACK using the same parameters it sent in its
* original INIT chunk (including its Initiate Tag, unchanged), provided
* that no NEW address has been added to the forming association. If
* the INIT message indicates that a new address has been added to the
* association, then the entire INIT MUST be discarded, and NO changes
* should be made to the existing association. An ABORT SHOULD be sent
* in response that MAY include the error 'Restart of an association
* with new addresses'. The error SHOULD list the addresses that were
* added to the restarting association.
*
* When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
* an INIT ACK, the original parameters are combined with those from the
* newly received INIT chunk. The endpoint shall also generate a State
* Cookie with the INIT ACK. The endpoint uses the parameters sent in
* its INIT to calculate the State Cookie.
*
* After that, the endpoint MUST NOT change its state, the T1-init timer
* shall be left running, and the corresponding TCB MUST NOT be
* destroyed. The normal procedures for handling State Cookies when a
* TCB exists will resolve the duplicate INITs to a single association.
*
* For an endpoint that is in the COOKIE-ECHOED state, it MUST populate
* its Tie-Tags within both the association TCB and inside the State
* Cookie (see Section 5.2.2 for a description of the Tie-Tags).
* </pre>
*/
public virtual Chunk[] inboundInit(InitChunk init)
{
Chunk[] reply = null;
_peerVerTag = init.getInitiateTag();
_winCredit = init.getAdRecWinCredit();
_farTSN = (uint)(init.getInitialTSN() - 1);
_maxOutStreams = Math.Min(init.getNumInStreams(), MAXSTREAMS);
_maxInStreams = Math.Min(init.getNumOutStreams(), MAXSTREAMS);
InitAckChunk iac = new InitAckChunk();
iac.setAdRecWinCredit(MAXBUFF);
iac.setNumInStreams(_maxInStreams);
iac.setNumOutStreams(_maxOutStreams);
iac.setInitialTSN(_nearTSN);
iac.setInitiateTag(_myVerTag);
CookieHolder cookie = new CookieHolder();
cookie.cookieData = new byte[Association.COOKIESIZE];
cookie.cookieTime = Time.CurrentTimeMillis();
_random.NextBytes(cookie.cookieData);
iac.setCookie(cookie.cookieData);
_cookies.Add(cookie);
byte[] fse = init.getFarSupportedExtensions();
if (fse != null)
{
iac.setSupportedExtensions(this.getUnionSupportedExtensions(fse));
}
reply = new Chunk[1];
reply[0] = iac;
Logger.Debug("Got in bound init :" + init.ToString());
Logger.Debug("Replying with init-ack :" + iac.ToString());
return(reply);
}
/*
*
*
* o The initial value of ssthresh MAY be arbitrarily high (for
* example, implementations MAY use the size of the receiver
* advertised window).
*/
void setSsthresh(InitChunk init)
{
this._ssthresh = init.getAdRecWinCredit();
}
/*
* 6.2.1. Processing a Received SACK
*
* Each SACK an endpoint receives contains an a_rwnd value. This value
* represents the amount of buffer space the data receiver, at the time
* of transmitting the SACK, has left of its total receive buffer space
* (as specified in the INIT/INIT ACK). Using a_rwnd, Cumulative TSN
* Ack, and Gap Ack Blocks, the data sender can develop a representation
* of the peer's receive buffer space.
*
* One of the problems the data sender must take into account when
* processing a SACK is that a SACK can be received out of order. That
* is, a SACK sent by the data receiver can pass an earlier SACK and be
* received first by the data sender. If a SACK is received out of
*
*
*
*
* Stewart Standards Track [Page 81]
*
* RFC 4960 Stream Control Transmission Protocol September 2007
*
*
* order, the data sender can develop an incorrect view of the peer's
* receive buffer space.
*
* Since there is no explicit identifier that can be used to detect
* out-of-order SACKs, the data sender must use heuristics to determine
* if a SACK is new.
*
* An endpoint SHOULD use the following rules to calculate the rwnd,
* using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in
* a received SACK.
*/
/*
* A) At the establishment of the association, the endpoint initializes
* the rwnd to the Advertised Receiver Window Credit (a_rwnd) the
* peer specified in the INIT or INIT ACK.
*/
public override Chunk[] inboundInit(InitChunk init)
{
_rwnd = init.getAdRecWinCredit();
setSsthresh(init);
return(base.inboundInit(init));
}