Tags: zaimramlan/swift-nio
Tags
HTTPDecoder: no error on unclean EOF on upgrade (apple#1063) Motivation: Previously we thought that if we have some bytes left that belong to an upgraded protocol, we should deliver those as an error. This is implemented on `master` but not in any released NIO version. However, no other handler sends errors on unclean shutdown, so it feels wrong to do it in this one very specific case (EOF on inflight upgrade with data for the upgraded protocol) Modifications: Remove the error again. Result: Less behaviour change to the last released NIO version.
enable TCP_NODELAY by default (apple#1020) Motivation: Networking software like SwiftNIO that always has explicit flushes usually does not benefit from having TCP_NODELAY switched off. The benefits of having it turned on are usually quite substantial and yet we forced our users for the longest time to enable it manually. Quite a bit of engineering time has been lost finding performance problems and it turns out switching TCP_NODELAY on solves them magically. Netty has made the switch to TCP_NODELAY on by default, SwiftNIO should follow. Modifications: Enable TCP_NODELAY by default. Result: If the user forgot to enable TCP_NODELAY, their software should now be faster.
undo tiny public API breakage Motivation: In apple#957 we accidentally broke the API just a little bit. We turned the `ByteToMessageHandler.init` from public init(_ decoder: Decoder) into public init(_ decoder: Decoder, maximumBufferSize: Int? = nil) This looks totally benign and in almost all cases because of the default argument, you wouldn't notice the API breakage. However, it's possible to write code that works in NIO 2.0.0 but breaks in NIO 2.1.0. For example let g: (Dummy) -> ByteToMessageHandler<Dummy> = ByteToMessageHandler<Dummy>.init let h: (Dummy) -> ByteToMessageHandler<Dummy> = ByteToMessageHandler<Dummy>.init(_:) Modifications: According to SemVer, this releases a patch that unbreaks the public API. Result: No API breakages (checked with `swift-api-digester` which also found the breakage in the first place).
B2MDError: nest PayloadTooLargeError (apple#998) Motivation: New public NIO types must be nested in existing ones or `NIO` prefixed. This wasn't the case for ByteToMessageDecoderPayloadTooLargeError Modifications: nest PayloadTooLargeError into ByteToMessageDecoderError Result: we stick to our rules.
Avoid keeping hold of partial bytes forever. (apple#984) Motivation: The HTTPDecoder is a complex object that has very careful state management goals. One source of this complexity is that it is fed a stream of bytes with arbitrary chunk sizes, but needs to produce a collection of objects that are contiguous in memory. For example, each header field name and value must be turned into a String, which requires a contiguous sequence of bytes to do. As a result, it is quite common to have a situation where the HTTPDecoder has only *part* of an object that must be emitted atomically. In this situation, the HTTPDecoder would like to instruct its ByteToMessageHandler to keep hold of the bytes that form the beginning of that object. To avoid asking http_parser to parse those bytes twice, the HTTPDecoder uses a value called httpParserOffset to keep track. As an example, consider what would happen if the "Connection: keep-alive\r\n" header field was delivered in two chunks: first "Connection: keep-al", and then "ive\r\n". The header field name can be emitted in its entirety, but the partial field value must be preserved. To achieve this, the HTTPDecoder will store an offset internally to keep track of which bytes have been parsed. In this case, the offset will be set to 7: the number of bytes in "keep-al". It will then tell the rest of the code that only 12 bytes of the original 19 byte message were consumed, causing the ByteToMessageHandler to preserve those 7 bytes. However, when the next chunk is received, the ByteToMessageHandler will *replay* those bytes to HTTPDecoder. To avoid parsing them a second time, HTTPDecoder keeps track of how many bytes it is expecting to see replayed. This is the value in httpParserOffset. Due to a logic error in the HTTPDecoder, the httpParserOffset field was never returned to zero. This field would be modified whenever a partial field was received, but would never be returned to zero when a complete message was parsed. This would cause the HTTPDecoder to unnecessarily keep hold of extra bytes in the ByteToMessageHandler even when they were no longer needed. In some cases the number could get smaller, such as when a new partial field was received, but it could never drop to zero even when a complete HTTP message was receivedincremented. Happily, due to the rest of the HTTPDecoder logic this never produced an invalid message: while ByteToMessageHandler was repeatedly producing extra bytes, it never actually passed them to http_parser again, or caused any other issue. The only situation in which a problem would occur is if the HTTPDecoder had a RemoveAfterUpgradeStrategy other than .dropBytes. In that circumstance, decodeLast would not consume any extra bytes, but those bytes would have remained in the buffer passed to decodeLast, which would then incorrectly *forward them on*. This is the only circumstance in which this error manifested, and in most applications it led to surprising and irregular crashes on connection teardown. In all other applications the only effect was unnecessarily preserving a few tens of extra bytes on some connections, until receiving EOF caused us to drop all that memory anyway. Modifications: - Return httpParserOffset to 0 when a full message has been delivered. Result: Fewer weird crashes. (cherry picked from commit ae3d298)
Simplify Heap implementation. (apple#961) Motivation: Our original Heap implementation used a bunch of static functions in order to make it clear how it related to textbook heap implementations. This was primarily done to ensure that it was easier to see the correctness of the code. However, we've long been satisfied with the correctness of the code, and the Heap is one of the best tested parts of NIO. For this reason, we should be free to refactor it. Given https://bugs.swift.org/browse/SR-10346, we've been given an incentive to do that refactor right now. This is because the Heap is causing repeated CoW operations each time we enqueue new work onto the event loop. That's a substantial performance cost: well worth fixing with a small rewrite. Modifications: - Removed all static funcs from Heap - Rewrote some into instance funcs - Merged the implementation of insert into append. - Added an allocation test to avoid regressing this change. Result: Faster Heap, happier users, sadder textbook authors. (cherry picked from commit f79c7ae)
PreviousNext