Test connection multiplexing across multiple servers and clients

[tegefaulkes]

Specification

We need to create tests that create an arbitrary number of connections across an arbitrary number of servers and clients.

The ultimate goal is to test that connection multiplexing and that connections function properly when run concurrently.

All the tests should be sending at least 1 stream of random data

Additional context

• Related Create QUIC library that can be exposed to JS and uses the Node dgram module #1

Tasks

• 1. Multiple clients connecting to a single server.
• 2. Multiple clients sharing a socket.
• 3. Clients sharing socket with server.
• 4. Random assortment of clients and servers communicating with each other.

[tegefaulkes]

QUICSocket.registerClient is a function that isn't implemented yet. What is it for? Do we need to track what clients are using the socket? I suppose we'd need it if stopping the socket cleans up anything using it such as the server and clients.

Thoughts @CMCDragonkai ?

[CMCDragonkai]

Yes you need to be able to keep track of clients too. You have to track all clients and servers of a given socket...

[CMCDragonkai]

Lifecycle rules too. Can't let a socket be destroyed with clients that exist.

[tegefaulkes]

So far for any tests on the connection level were I need to test a connection to a server I've been putting them in the QUICClient.test.ts test file. This file is getting pretty large, I may want to split it up into files that test certain aspects. Such as the server/client concurrency testing.

[CMCDragonkai]

You can separate it with QUICClient.X.test.ts. Where X are the different variants.

[tegefaulkes]

Destroying a connection might be hanging if no streams were created. It might be test specific, I'll need to dig into this.

[tegefaulkes]

Found a bug. In certain scenarios client streams are not fulling cleaning up when they are meant to be ended. This is similar to the previous one I fixed where streams are not listed as readable or writable after they have finished. This means we are not checking them after the last state change. Previously this was fixed by adding streams to a short list to be checked when destroying.

The problem here however is that we're not entering the destroying state, we're waiting for the readable side to end during normal operation. So the previous fix to the logic doesn't apply here.

I think given this we need to check all active streams indiscriminately. This means an O(n) loop every time we receive data on a connection. This is frustratingly not ideal from a performance perspective but it's still linear time so not the end of the world.

[tegefaulkes]

Notably, the examples don't maintain state for the streams. but it does for the connections. Every time the socket receives a packet, it handles the packet and processes any events on the streams, readable and writable.

After processing all incoming packets, it process all clients for outgoing packets, then checks all clients again if they have closed so it can clean them up.

I think that means the only solution here is to check every active stream for a state change after we process a recv for that connection. but we still need to check the readable list for new streams.

The available methods here for processing events are fine for the example since it processes reads and write statelessly. if the stream has ended then we're just not processing them as part of the readable or writable list.

Ultimately the solution here is to process the readable list so we can create state for new streams. We can then iterate over all the existing streams checking if they're writable and process any state changes.

There is an unknown here. If the stream has ended with a shutdown before any data was sent to create remote state. Is that stream considered readable? Would state for it be created? Do we care if it isn't?

Anyway, changes to be made include...

1. for a recv call for a connection, we need to iterate over all the readables to create state for the streams, process any recv stream data.
2. after that we need to iterate over over all existing connections processing the isWritable(), check the status of the readable and writable state and trigger any state change for the QUICStream.
3. I need to double check some expected logic. What does the stream state look like for a stream that was destroyed before any data was sent. That would look like a STREAM_RESET event for the readable. Would that stream be readable at all? would we create state for it? would there be anything to process?