The main issue in the article are calls to getaddrinfo() on every send which create a delay, which is not only DNS related. The function does DNS lookups but also translates IP address strings to address data that can be used by the kernel (e.g. the different ways to write IPv6 addresses like “fe80::1%eth0”)
The question I have is why were those lookups a problem in the first place? It's just a metric, is it really important that it's sent one tick later?<p>As another commented pointed out the "solution" only uses a single IP, even if the resolver returned multiple.<p>I would not use this in production.
Looking at the UDP code in question in brightcove/hot-shots [1]. The createUdpTransport() function creates an object with a send() method that forwards to socket.send(), calling the underlying function with the same host and port argument each time. It seems to me that this code should call socket.connect(args.host, args.port) once instead, and skip the host and port arguments to the send() calls. Presumably this would result in just a single DNS lookup.<p>Bonus: the createUdpTransport() function <i>also</i> has a DNS cache, which the author of the article could have enabled with just "cacheDns: true". But if the library code used socket.connect(), this internal cache shouldn't be needed either.<p>1: <a href="https://github.com/brightcove/hot-shots/blob/564ac7bfdaaf3669232b4941b4695ef72ae6531e/lib/transport.js#L46" rel="nofollow">https://github.com/brightcove/hot-shots/blob/564ac7bfdaaf366...</a>
Maybe not everybody cares about the wasted tick, but the response to such niche feature requests in open source projects used to be a simple “patches welcome”. I found that way more helpful and less aggressive than what seems to be the new default in Github projects, “won’t fix”. I don’t understand this shift.
An alternative approach would be to call "await util.promisify(socket.connect)(8125, host)" so that subsequent calls to send don't need to name the destination (and the underlying runtime could call send instead of sendto). Perhaps the author needs the messages to be sent to a new host quickly when DNS records change, but the trade-off might be different depending on the use case, and perhaps some applications might prefer to periodically re-connect the socket to re-resolve DNS.
is `send2` supposed to be the node version of UNIX `sendto(2)`? [1]<p>I don't see `send2` in the node docs[2].<p>[1] <a href="https://beej.us/guide/bgnet/html/#sendtorecv" rel="nofollow">https://beej.us/guide/bgnet/html/#sendtorecv</a>
[2] <a href="https://nodejs.org/api/dgram.html" rel="nofollow">https://nodejs.org/api/dgram.html</a>