ywave620

Seems like the fix is just as simple as  Any ritual to do before changing the public API? @ajkr

@DevasiaThomas I believe this is just the known issue as memtioned by @ronag and @bnoordhuis. For you curiosity why > an outgoing ACK (not FIN,ACK) to an incoming FIN (on...

FYI, the TCP FIN, in nodejs spectrum, is the 'end' event of a socket. I don't see any code of http agent makes use of this event to decide whether...

> Node.js Client sends FIN, ACK --> This has no problem, works fine This is the default behavior of a nodejs client/server, i.e. nodejs automatically close any half-open connection. This...

Also note that `allowHalfOpen` is not officially documented in `http` module. Is it intended or do we miss it? @ronag

`allowHalfOpen` applies to either client or server. It make sense in `net` abstraction level, however, it is copied to the option paased to `net` by `http`. E.g. `net.createConnection` inherits the...

I opt for keeping the firehose approach incoming connections/data. io_uring has a handy feature called multshot(https://man.archlinux.org/man/io_uring.7.en#IORING_CQE_F_MORE), applicable to accept(43), read(0). Multshot can be depicted as one submission(SQE), multiple completeness(CQE). This...

If we switch reading from handle-based to request-based, the first dilemma comes to me is that how we submit read operation to io_uring, one by one (`io_uring_enter(ring_fd, 1/*to_submit*/, ...)`) or...

> If we switch reading from handle-based to request-based, the first dilemma comes to me is that how we submit read operation to io_uring, one by one (`io_uring_enter(ring_fd, 1/*to_submit*/, ...)`)...