https://bugs.winehq.org/show_bug.cgi?id=48293
--- Comment #15 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 66191 --> https://bugs.winehq.org/attachment.cgi?id=66191 Log with patch 66190
The patch does help, but I don't know if it's in the expected way (I hope it is, because behavior is much better).
With previous configurations, every time I clicked UI objects there were WS_getaddrinfo requests passed to resolver (for "wpad.myhost" or "wpad."). "wpad.myhost" was sent over DNS, which returned "not found" after about 100 ms, and the result was cached, so subsequent queries were handled in about 10 ms (measured with 'time resolvectl'). "wpad." was sent over LLMNR [1], and since there is no such host on the local network, it timed out -- but not after two retries and waiting 250 ms after each message, totaling in over 750 ms of delay. And the result was not cached, so every request took such a long time.
With this patch there are no WS_getaddrinfo requests *at all* when clicking UI objects. There are requests for "wpad", but they are not at any specific timestamps. I attached log with this patch (and no domain set), switched games again at timestamps 70, 80, 90 and 100; and "wpad" is queried at about 52, 61 and 98.
Looking more carefully at previous logs I can also see that there were requests for "wpad" (without the dot), mixed with the ones with the dot: $ grep -c '"wpad.' *.txt domain.txt:50 nodomain.txt:54 $ grep -c '"wpad"' *.txt domain.txt:7 nodomain.txt:5 And with the patch there are just 5 requests in total (instead of almost 60): $ grep -c wpad *.txt nodomain-trailingdotpatch.txt:5
[1] From systemd-resolved manual: "Single-label names are routed to all local interfaces capable of IP multicasting, using the LLMNR protocol." If I disabled LLMNR the requests were handled much quicker, but then I didn't have local name resolution on my network, which I use.