Should we add a name to unnamed struct QUIC_HANDLE in the state?

[Koishilll]

Should we add a name to unnamed struct QUIC_HANDLE in the state?

I notice the struct QUIC_HANDLE in connection.h is different to others:

//
// Connection-specific state.
//   N.B. In general, all variables should only be written on the QUIC worker
//        thread.
//
typedef struct QUIC_CONNECTION {

#ifdef __cplusplus
    struct QUIC_HANDLE _;
#else
    struct QUIC_HANDLE;
#endif

vs listener.h

//
// Represents the Listener specific state.
//
typedef struct QUIC_LISTENER {

    struct QUIC_HANDLE;

Since the anonymous struct is only available in C and not permitted in C++ (it will be treated as a declaration, but not occupy a space), is it necessary to add a name to the struct QUIC_HANDLE in the other state?

P.S.: I'm trying to get native socket from the listener, to get the firewall to accept the inbound packets, after I send something off first. But after I do that, my C++ program crashes due to memory access violation, because of the different offset in C and C++.

[nibanks]

Should we add a name to unnamed struct QUIC_HANDLE in the state?

If you want C++ code to access a QUIC_LISTENER object, yes, you need to do the same thing as what is done for QUIC_CONNECTION. But the better question is why are you trying to access the inner struct format? The only reason we ever do it like this is for unit tests. Code external to the MsQuic library should be using the public API to access things.

P.S.: I'm trying to get native socket from the listener, to get the firewall to accept the inbound packets, after I send something off first.

What exactly are you trying to do with the socket? How will you handle the fact that MsQuic has per-processor sockets, and not just one, for the listener?

Depending on what you're trying to do, the following would likely be better alternatives:

1. Add a new param to the listener to do whatever you're trying to do for the firewall, and put that logic in MsQuic. Do you think any other app would need to do the same?
2. Add a new param to the listener to return the socket handle. This is dangerous because there is no lifetime management here. What happens if MsQuic ends up deleting the socket while your app still is using it?

[Koishilll]

What exactly are you trying to do with the socket?

Well, the reason for doing this is kind of long. I want to develop a P2P-based game synchronization library, so I want to find a protocol that is faster than TCP but also provide reliable connection, and then I choose QUIC.

After I learn how the firewall works (discard packets before sending first), I want to give a foolproof way to the end user so that if two players knows their addresses and ports, they can connect to each other at the same time, without configuring their firewall.

In my design, every endpoint have these structure:

• a sentinel (UDP socket at port A)
• a server (MsQuic Listener at port B)
• a client (MsQUic Connection at port C)

Users just need to share their address and port A to each other. Sentinel tells the other ports to the remote endpoint, then endpoint1 send a small packet from B1 to C2, so endpoint2's C2 can connect to endpoint1's B1 without being discarded by the firewall. And endpoint2 does the same thing.

What I am doing is extracting the native socket from the listener, sending a small packet by sendto(), and just ignore it.

By the way, the best way to implement this is to let port B and C to be the same, but MsQuic doesn't support this for now. But but QUIC protocol does support it, right?

How will you handle the fact that MsQuic has per-processor sockets, and not just one, for the listener?

I don't know exactly how it works, but I guess it should be like what TCP does: call accept() on an unconnected socket, and we get a connected socket. But unlike TCP, there are some routines in MsQuic rather than accept(), and we can call sendto() with the parameter remote address not being ignored because it's a UDP socket. In fact, it really works.

I admit that it is a bad attempt to get a socket from the internal format, so I don't think what I am doing should be added to MsQuic. Instead, maybe it is possible to adding support for opening Connections on a Listener's port. I haven't investigated why it doesn't support yet, but I am wondering why, and is anyone dealing with it now?

[nibanks]

Effectively, you're trying to do ICE, or at least part of it, to punch through NATs. Several others have been interested in supporting this in MsQuic, and in fact the IETF just had some significant discussions last week on how to better support it with the QUIC protocol in general. I approved your PR, because it's still goodness, but I'd love to see a more general solution here that others could benefit as well. Would you be interested in working with us to try to have some level of native NAT punch through support here?

[Koishilll]

Yes, I'd love to work on it and see the change! If it's what I can achieve.