Subject: bug#45821: Emacs UDP support on Windows

From: Robert Pluim <[email-masked]>
Date: Mon, 02 Jan 2023 11:22:03 +0100

>>>>> On Mon, 2 Jan 2023 00:47:12 +0000, Alex Matei <[email-masked]> said:

    Alex> Updates on the UDP patch behavior:
    Alex>   *   I got confused during my validation by 2 things:
    Alex>      *   ‘dns-query’ works even without your patch changes
    Alex>   => it is not a good test ❌

`dns-query' by default uses TCP on MS-Windows when thereʼs no UDP
support. You can use it, but youʼd have to either instrument it or
check your network traffic using wireshark or similar.

    Alex>         *   One test that worked for me was using ‘(make-network-process :name "udp-socket1" :remote '[127 0 0 1 1500] :type 'datagram)’
    Alex>            *   If returns ‘(error "Unsupported connection type")’ if UDP is disabled ❌ , or the process if UDP is allowed✅

(featurep 'make-network-process '(:type datagram)) is the canonical
way to check that. And it only proves you can create UDP sockets, not
that they work 😉

    Alex>      *   The original patch doesn’t include the #define for ‘WORKING_SELECT_EMULATION’, and I had to manually add this define to my emacs build (via 'CFLAGS= -O0 -g3 -DWORKING_SELECT_EMULATION' )
    Alex>         *   That’s why I got confused about the patch working initially , since my assumption was that if ‘dns-query’ works => UDP works as expected😉and I didn’t even consider that I was required to set up some more flags..

    Alex> ❌ Indeed, TLS is broken -> Eww to https://www.gnu.org<https://www.gnu.org/> fails to load the page ( see attached image – Emacs instance on the left, compiled with UDP patch, didn’t load gnu.org while on the right side- default Emacs build for 28.1 opens it without any issues)

Yep. Last time I looked at this, the TLS handshaking fails to complete
(see src/process.c around line 5329 and the checking against
GNUTLS_EMACS_HANDSHAKES_LIMIT) which means weʼre continually retrying
the handshake without giving the remote end a chance to send us
anything. Which I think means that our state machine for TLS
negotiation is subtly incorrect, but only on MS-Windows.

Robert
--