TCP/UDP socket type selection inconsistency

[nebkat]

Is your feature request related to a problem? Please describe.
dgram.Socket requires the socket type (udp4 or udp6) to be provided in its constructor (dgram.createSocket), and uses this socket type regardless of the local and remote addresses.

net.Socket does not require the socket type to be provided in advance, and performs dns.lookup() with the family parameter given in net.Socket#connect() to determine the socket type. Unlike dgram.Socket, it performs socket binding when a connection is requested, so the local address/port can also be provided as parameters if needed, but the socket type is still determined by the remote host (which makes sense as net.Server deals with bound but unconnected sockets).

net.Server uses an IPv6 socket by default, unless an IPv4 address is explicitly provided in net.Server#listen().

This results in inconsistent default behavior when comparing TCP and UDP, both for servers and clients. It should be possible to have the UDP socket type be determined by the provided addresses, both for servers and clients.

Even if udp6 is chosen, which would in theory work the same for both types of remote addresses, the DNS resolution is inconsistent for TCP/UDP clients. TCP resolution defaults to family type 0, while UDP would use family type 6, so the resulting IP address will be different if the nameserver normally resolves to IPv4 first.

See lib/internal/dgram.js#newHandle, lib/net.js#internalConnect and lib/net.js#createServerHandle.

Describe the solution you'd like

• dgram.Socket should not require a socket type in its constructor.
• dgram.Socket#bind() should match the net.Server#listen() behavior and use an IPv6 socket by default, unless and IPv4 address is explicitly provided.
• dgram.Socket#connect() should match the net.Socket#connect() behavior and resolve the remote address to determine the socket type, crucially before the bind() call is made.
• If the socket is already bound when connect() is called, the functionality should remain as it is currently, where the dns.lookup() call is made with the family parameter set. If only IPv6 is resolved on an IPv4 bound socket, an error is thrown.
• The socket type currently provided in the constructor could set an internal default address for cases when no local or remote addresses are provided to bind() and connect(), until this method is deprecated, after which the default address would become ::1 in both cases.

Describe alternatives you've considered

• dns.lookup() can be performed manually before the socket is created to decide udp4/udp6, but this greatly complicates the socket creation flow. This could be moved to dgram.createConnection or similar, but this wouldn't fully solve the TCP/UDP client inconsistency.
• If using IPv6 by default is acceptable, the lookup parameter of dgram.createSocket can be set to a wrapper around the default dns.lookup(), with the family type set to 0 instead of 6 and if the result is IPv4 it can be manually mapped to IPv6. This again complicates the socket creation flow.
• The previous alternative could be simplified if family and hints could be provided as is possible in net.Socket#connect(), but this doesn't solve the core problem.

[nebkat]

I would be happy to contribute to making this change but seeing as it is a relatively important part of the API I'd like to gather opinions first to see if there are any issues in the way.

[bnoordhuis]

The big question is: is there a non-zero chance it'll break existing code? I would say there is. Just phasing out the .type property will take several major releases.

There are also some lesser questions like: how would it work with socket.bind({ fd: 42 })?

Personally speaking, the upsides seem marginal compared to the ecosystem fallout risk. The module works well enough in its current shape.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[mkovatsc]

This issue is originally about consistency with the node:net module, but there is a bigger issue with having to provide the socket type upfront: when the application only has a host name, it can only know after the (m)DNS lookup whether it requires udp4 or udp6. This renders the DNS resolution inside the dgram.Socket rather pointless (as the application has to do it upfront) or causes delay for waiting a first attempt to fail (e.g., first try udp4 and on error retry with udp6) -- opportunistically opening both turns bad when both work.

I see this as "enough upside" or rather necessary to allow for omitting the socket type in the constructor.