Opened as a draft because the tests don't pass currently.

@jasnell I found a bit of weirdness in the implementation.

It's mentioned in the test comments but if you call sendDatagram too soon after staring the session, this check returns false so the datagram is not sent.

I would have thought that datagrams would be sendable after the opened promise on the session resolves but it appears not.

After waiting for an arbitrary period the datagram is sent but is received multiple times. Is the user supposed to filter these duplicates out or is it an implementation bug?

Finally if you close the server listener without first closing any active sessions a segfault occurs. If you do close the sessions first, the promise returned from the listener .close() method resolves, but the process keeps running.

The segfault stack trace is:

----- Native stack trace -----

 1: 0x10456cf44 node::DumpNativeBacktrace(__sFILE*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 2: 0x1046dbf98 node::Assert(node::AssertionInfo const&) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 3: 0x104aa6048 node::quic::Endpoint::local_address() const [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 4: 0x104aaa1e4 node::quic::Endpoint::Receive(uv_buf_t const&, node::SocketAddress const&) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 5: 0x104aa2964 node::quic::Endpoint::UDP::Impl::OnReceive(uv_udp_s*, long, uv_buf_t const*, sockaddr const*, unsigned int) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 6: 0x1063f1660 uv__udp_recvmsg [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 7: 0x1063efe74 uv__udp_io [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 8: 0x1063f6a6c uv__io_poll [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 9: 0x1063d1fe8 uv_run [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
10: 0x10449d100 node::SpinEventLoopInternal(node::Environment*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
11: 0x104765288 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
12: 0x104764ef0 node::NodeMainInstance::Run() [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
13: 0x104639830 node::StartInternal(int, char**) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
14: 0x10463944c node::Start(int, char**) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
15: 0x1069fa1c4 main [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
16: 0x1827d0274 start [/usr/lib/dyld]
FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope

..so it looks like maybe the client is still sending the duplicate datagrams to the server even after the session has been closed.

The behaviour appears to be due to setting the NGTCP2_WRITE_DATAGRAM_FLAG_MORE flag here.

When it's set, we hit this branch and add the same datagram to the outgoing packet over and over again hence all the duplicates.

Setting the flag value to 0 makes ngtcp2_conn_writev_datagram return a positive value and the listener receives the datagrams and the test passes, though it still segfaults when trying to shut the server down afterwards.

@achingbrain ... just FYI I haven't had the chance to take a look at this yet but I intend to soon! It will likely be in the next few days. Really appreciate your taking a look at this tho!

This pull request has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

While this is likely safe to close, I want to keep it open for now until @nodejs/quic team is sure the test coverage is adequate.