CMCDragonkai
commented
1 year ago Ok I have managed to get the ability for quiche to send a packet. Actually I haven't sent the packet to the UDP socket, but I can see how quiche attempts to create an initial packet for me plumb into the UDP socket.
This involved several challenges.
The first is that self.0.send takes in a reference to a mutable buffer. There's a preference to avoid copying in Rust lang similar to C and C++.
This buffer can actually be taken from the outside back in JS land. This might be a better idea, as it minimises the amount of copy pasting going on.
Alternatively we can create the array in Rust, then return as a Buffer. However the send call returns the number of bytes written.
Therefore the buffer is pre-allocated to be MAX_DATAGRAM_SIZE and it is subsequently written to.
This means later the array needs to be sliced according the to the write size and then returned as a buffer.
This means we generally 2 styles of calling the Rust functions. We can call them the way rust expected to be called, by passing in a buffer as a parameter and returning the write length as well. It turns out that socket.send actually easily supports taking a buffer, offset and the length to be used: https://nodejs.org/api/dgram.html#socketsendmsg-offset-length-port-address-callback. In terms of speed, it would make use to re-use the same buffer over and over.
The other way is more idiomatic JS, which would mean that the function should return the buffer to be sent that is properly sliced up.
I think we should preserve the rust style, and then do any JS-specific idiomatic abstractions on the JS side.
At the same time, the send can also return an error which indicates that it is Done. If it is done, then there are no more packets to send. Using a JS style call, we can just return undefined in that situation. However I'm not entirely sure if this is actually possible using napi-rs. It seems you have return a Rust value, and that it automatically gets converted to JS via the napi-rs macros.
With rust style calls, the done is returned as an exception which is kind of strange, but also doable. But this is very much different from how JS should be used, and it means we also have to catch non-done exceptions.
Another thing to realise is that when you have situations where you have a buffer of some fixed size, and a then write length indicating how much of that buffer was used. This will always eventually lead to a slicing operation.
When doing any slicing, the function's stack will end up with a pointer (reference) to the slice, it won't do any copying.
Rust does not have dynamically allocated arrays that sit on the stack, so you have to use vectors instead. Vectors are heap-allocated arrays that can be dynamically changed. String is also heap allocated string relative to &str. At the same time, Rust manages the memory of vectors and knows when to deallocate them automatically.
So if we wanted to slice out from the array and also return it as a Buffer to JS, then it has to be turned into a vector first, and that vector will be dynamically allocated simply through the !vec macro.
Finally another problem is sending structs back to JS as objects. This requires hte usage of #[napi(object)] macro. However this only works on structs have all the fields public.
The send info contains information that is necessary to know how to send the packet data to the UDP socket.
It however ends up containing std::net::SocketAddr and std::time::Instant both which contain private fields. So these types cannot be easily automatically converted to JS object. It could probably be done if I implement some sort of interface for the SocketAddr. Like https://docs.rs/napi/latest/napi/trait.NapiRaw.html and https://docs.rs/napi/latest/napi/trait.NapiValue.html.
Alternatively I created my own Host struct that just contains a String and u16. This results in a conversion from the SocketAddr to Host and wrapping std::time::Instant into External::new() because it's supposed to be opaquely compared at the rust-level.
This led to a few other issues:
- You cannot declare nested structs in Rust, you have to give each one a separate name.
- There does not appear to be a way to send Rust tuples to JS, napi-rs does not understand how to deal with tuples. I would have thought that they just become arrays on the JS side... but no.
- Rust enums cannot be represented either, they become objects on the JS side. This is because Rust enums are actually ADTs. They have a tag, and then the subsequent value/values.
So with this all in mind, I ended up creating another custom struct just so that so I can get the value out of conn.send.
This reveals a structure that always contains the initial packet. This is probably the packet that leads to connection negotiation. If you call it again right now, you get a JS error with Done as the message.
{
out: <Buffer c3 00 00 00 01 10 98 f4 9d 84 85 7a dd 8e f6 ef fe 25 d7 84 b3 e1 14 d3 46 1a ab 5d d2 25 f2 61 c7 0d b0 d7 83 10 88 f0 b3 f8 eb 00 40 e8 58 ad 8e 1e ... 1150 more bytes>,
info: {
from: { hostname: '127.0.0.1', port: 55551 },
to: { hostname: '127.0.0.1', port: 55552 },
at: [External: 2d723f0]
}
}Now we can just plumb this into the dgram module to send.
Specification
We need QUIC in order to simplify our networking stack in PK.
QUIC is a superior UDP layer that can make use of any UDP socket, and create multiplexed reliable streams. It is also capable of hole punching either just by attempting to send ping frames on the stream, or through the unreliable datagrams.
Our goals is to make use of a QUIC library, something that is compilable to desktop and mobile operating systems, expose its functionality to JS, but have the JS runtime manage the actual sockets.
On NodeJS, it can already manage the underlying UDP sockets, and by relying on NodeJS, it will also ensure that these sockets will mix well with the concurrency/parallelism used by the rest of the NodeJS system due to libuv and thus avoid creating a second IO system running in parallel.
On Mobile runtimes, they may not have a dgram module readily available. In such cases, having an IO runtime to supply the UDP sockets may be required. But it is likely there are already existing libraries that provide this like https://github.com/tradle/react-native-udp.
The underlying QUIC library there is expected to be agnostic to the socket runtime. It will give you data that you need to the UDP socket, and it will take data that comes of the UDP socket.
However it does need 2 major duties:
Again if we want to stay cross platform, we would not want to bind into Node.js's openssl crypto. It would require instead that the library can take a callback of crypto routines to use. However I've found that this is generally not the case with most existing QUIC libraries. But let's see how we go with this.
Additional context
QUIC and NAPI-RS
Sub issues
2
3
4
5
6
7
8
9
10
13
14
15
16
17
18
Tasks
Configso the user can decide this (especially since this is not a HTTP3 library). - 0.5 day~ - see #13null. Right now when a quiche client connects to the server, even after closing, the server side is keeping the connection alive. - 1 dayQUICConnectionandQUICStreamandQUICServerandQUICSocket. This will allow users to hook into the destruction of the object, and perhaps remove their event listeners. These events must be post-facto events. - 0.5 dayQUICStreamand change to BYOB style, so that way there can be a byte buffer for it. Testing code should be able generator functions similar to our RPC handlers. - 1 day~ - see #5.QUICClientwith the shared socketQUICSocket. - 3 dayQUICClientand a singleQUICServer. - 1 day~ - See #14rinfofrom the UDP datagram into theconn.recv()so that the streams (either during construction or otherwise) can have itsrinfoupdated. Perhaps we can just "set" therinfoproperties of the connection every time we do aconn.recv(). Or... we just mutate theconnparameters every time we receive a UDP packet.~ - See #16stream.connectionthey can acquire the remote information and also all the remote peer's certificate chain.~ - See #16napiprogram into thescripts/prebuild.jsso we can actually build the package in a similar to other native packages we are using likejs-db~ - see #7