quicker
quicker copied to clipboard
rmarx
NodeJS implementation of the QUIC protocol
right now, we throw errors like crazy, and almost never properly deal with them, instead letting us crash. Instead, either make them error logs (if we can ignore the situation)...
Large parts needs to be refactored/fixed, this issue is just a list of things that need to be done, more or less in order of importance: Main: - Flow control:...
StreamIDBlocked is apparently small enough (2 bytes) to trigger the sampleOffset problem with low packet numbers. Solution: Properly pad too small packets (probably best directly in encrypted.packet.ts:getFrameBuffer).
In commit 75eb1da0dca3a6944679ffa288955da448e9d2ea we added proper overlapping data support to Stream. However, CryptoStream is not descended from Stream, and so will need to be updated too. Probably ,we can revert...
https://github.com/rmarx/quicker/commit/a4669d30e217ee3190bb99fd66e1de6a02f81a0d should be reflected in the main branch as well TODO first: figure out what is happening exactly first. Seems like the fix might be better as a
The "localOffset" (and probably other things) of the connection-level flow control never changes. The streams do not emit events for this and the connection doesn't listen to them. Probably better...
At the moment, doing `QuicStream.end()` without buffering new data will result in the stream end not being sent to the other endpoint. This is a result of zero-length QUIC frames...
In file src/flow-control/flow.control.ts in function getStreamFrames(...) there is an infinite loop due to ableToSend(...) [from flow.controlled.ts]having to return lessThanOrEqual(temp) instead of lessThan(temp) ableToSend should probably be refactored to a more...
When a client tries to create a unidirectional stream towards a server, the server will throw a `PROTOCOL_VIOLATION` QuicError in the `handleMaxStreamDataFrame` function (specifically in the `Stream.isReceiveOnly()` condition). Commenting out...