tree 8fb240e1356dd84d79c45e52d18895a316cb7e43
parent bc746e3e9c91dc98e5c886a76f602364a78d5b1b
author David Benjamin <davidben@chromium.org> 1428221180 -0400
committer Adam Langley <agl@google.com> 1428353484 +0000

Remove buffering out records from the next epoch.

It was only ever enabled for handshake and alert messages. The comments cite
renego as a use case though even then I'm not clear on why. The only use I see
is if, say, the Finished message and ClientKeyExchange came in out-of-order.
DTLS is unreliable so leaning on retransmit seems fine, and usually flights
will be packed into one packet where possible. NSS doesn't have any such
buffer and doesn't seem to have problems.

The buffering mechanism is also rather dubious. It stows away the entire packet
and read buffer---all 16K of it---and there may have been other records in that
packet.

Change-Id: Ic3b7bf817be380dc73102eec62c690ed093e6667
Reviewed-on: https://boringssl-review.googlesource.com/4238
Reviewed-by: Adam Langley <agl@google.com>