SIGABRT: Whole simulation aborted after full RX buffer.

[tnull]

I'm running into an issue where for some reason a stream RX buffer is filled up. While I have to figure out the reason for this on my side, it currently results in the whole simulation being aborted, due to https://github.com/signetlabdei/quic/blob/master/model/quic-stream-base.cc#L490.

I'm not sure that this is the intended behavior. Especially for larger simulations where the transport protocol is only one piece fo the puzzle, the entire simulation should likely not crash if a single buffer is full.

Please find attached the corresponding backtrace.

[tnull]

I further investigated this issue. Contrary to the error messages provided by QuicStreamBase, the RX buffer is not full, but simply a duplicate packet is received:

+3.454451193s 469 QuicStreamBase:Recv(): [INFO ] Buffering unordered received frame - offset 9, frame offset 0
+3.454451193s 469 QuicStreamRxBuffer:Add(): [INFO ] Try to append 9 bytes , availSize=10485751
+3.454451193s 469 QuicStreamRxBuffer:Add(): [WARN ] Discarded duplicate packet.
+3.454451193s 469 QuicStreamBase:Recv(): [WARN ] Dropping packet due to full RX buffer
aborted. msg="Aborting Connection", +3.454451193s 469 file=../contrib/quic/model/quic-stream-base.cc, line=490
libc++abi.dylib: terminating

While I'm not entirely sure what would be the best approach to handle this case, I'm positive that this should not result in aborting the entire simulation. As I suppose the connection was aborted for a reason in case of a full RX buffer, I propose to signal this to L5. See this PR for the proposed changes: https://github.com/signetlabdei/quic/pull/14

[tnull]

I'm closing this issue since it was addressed by the just-merged pull request https://github.com/signetlabdei/quic/pull/14.

However, I'm still investigating why I'm seeing duplicate packets in the first place, and may reopen another issue on matter.