Menu ▾ ▴

#99 Windows server not working with UDP -u and -P on the client

1.0
closed
Robert McMahon
None
2021-03-01
2021-02-24
Robert McMahon
No

Windows UDP server, per a client's use of -P, isn't causing the operating system to dispatch UDP events properly, per the full quintuple (after a connect()) and new subsequent traffic threads destined to the same port. Note: SO_REUSEADDR is set. Hence, the listener thread isn't causing parallel servers to get started even though the quintuple (per the connect()) should provide peer end uniqueness.

This works for other platforms. A connected traffic thread and a bound (via bind()) listener thread need to run in parallel and do so except with Windows.

More as described here.

netstat expected is the full quintuple, as shown with linux

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)    
udp4       0      0  10.211.55.2.5000       10.211.55.2.6666
udp4       0      0  *.5000                 *.*

But get this with Windows

  Proto  Local Address          Foreign Address        State
  UDP    0.0.0.0:5000           *:*
  UDP    0.0.0.0:5000           *:*

Windows documentation says

For a connectionless socket (for example, type SOCK_DGRAM), the operation performed by WSAConnect is merely to establish a default destination address so that the socket can be used on subsequent connection-oriented send and receive operations (send, WSASend, recv, and WSARecv). Any datagrams received from an address other than the destination address specified will be discarded. If the entire name structure is all zeros (not just the address parameter of the name structure), then the socket will be disconnected. Then, the default remote address will be indeterminate, so send, WSASend, recv, and WSARecv calls will return the error code WSAENOTCONN. However, sendto, WSASendTo, recvfrom, and WSARecvFrom can still be used. The default destination can be changed by simply calling WSAConnect again, even if the socket is already connected. Any datagrams queued for receipt are discarded if name is different from the previous WSAConnect.

Discussion

  • Robert McMahon

    Robert McMahon - 2021-02-24
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,4 +1,6 @@
-Windows connect() isn't causing the operating system to dispatch both the full quintuple and subsequent traffic threads per -P.  [As described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).
+Windows connect() isn't causing the operating system to dispatch both the full quintuple and subsequent traffic threads per -P.   So the listener thread isn't causing parallel servers to get started even though the quintuple has uniqueness.
+
+[As described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).

 netstat expected is the full quintuple, as linux
     

  • Robert McMahon

    Robert McMahon - 2021-02-24
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,4 +1,4 @@
-Windows connect() isn't causing the operating system to dispatch both the full quintuple and subsequent traffic threads per -P.   So the listener thread isn't causing parallel servers to get started even though the quintuple has uniqueness.
+Windows connect() isn't causing the operating system to dispatch both the full quintuple and new subsequent traffic threads per a client's use of -P.   So the listener thread isn't causing parallel servers to get started even though the quintuple has uniqueness. This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel.

 [As described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).
     

  • Robert McMahon

    Robert McMahon - 2021-02-25
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,8 +1,10 @@
-Windows connect() isn't causing the operating system to dispatch both the full quintuple and new subsequent traffic threads per a client's use of -P.   So the listener thread isn't causing parallel servers to get started even though the quintuple has uniqueness. This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel.
+Windows UDP server, per a client's use of -P, isn't causing the operating system to dispatch UDP events properly, per the full quintuple (after a connect()) and new subsequent traffic threads destined to the same port. Note: SO_REUSEADDR is set.   Hence, the listener thread isn't causing parallel servers to get started even though the quintuple (per the connect()) should provide uniqueness. 

-[As described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).
+This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel and do so excpet with Windows.

-netstat expected is the full quintuple, as linux
+More [as described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).
+
+netstat expected is the full quintuple, as shown with linux

 ~~~
 Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)    
@@ -10,7 +12,7 @@
 udp4       0      0  *.5000                 *.* 
 ~~~

-But get
+But get this with Windows
 ~~~
   Proto  Local Address          Foreign Address        State
   UDP    0.0.0.0:5000           *:*
     

  • Robert McMahon

    Robert McMahon - 2021-02-25
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,4 +1,4 @@
-Windows UDP server, per a client's use of -P, isn't causing the operating system to dispatch UDP events properly, per the full quintuple (after a connect()) and new subsequent traffic threads destined to the same port. Note: SO_REUSEADDR is set.   Hence, the listener thread isn't causing parallel servers to get started even though the quintuple (per the connect()) should provide uniqueness. 
+Windows UDP server, per a client's use of -P, isn't causing the operating system to dispatch UDP events properly, per the full quintuple (after a connect()) and new subsequent traffic threads destined to the same port. Note: SO_REUSEADDR is set.   Hence, the listener thread isn't causing parallel servers to get started even though the quintuple (per the connect()) should provide peer end uniqueness. 

 This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel and do so excpet with Windows.
     

  • Robert McMahon

    Robert McMahon - 2021-02-25
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,6 +1,6 @@
 Windows UDP server, per a client's use of -P, isn't causing the operating system to dispatch UDP events properly, per the full quintuple (after a connect()) and new subsequent traffic threads destined to the same port. Note: SO_REUSEADDR is set.   Hence, the listener thread isn't causing parallel servers to get started even though the quintuple (per the connect()) should provide peer end uniqueness. 

-This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel and do so excpet with Windows.
+This works for other platforms.  A connected traffic thread and a bound (via bind()) listener thread need to run in parallel and do so except with Windows.

 More [as described here](https://stackoverflow.com/questions/59779711/problems-using-udp-sockets-bound-to-the-same-port-on-window).
     

  • Robert McMahon

    Robert McMahon - 2021-02-28

    Added support for multiple listeners using -p m-n, e.g iperf -s -p 6000-6007 and --incr-dstport on the client, e.g. iperf -c host -p 6000 --incr-dstport -P 8 or -p 6000-6007

     

    Last edit: Robert McMahon 2021-02-28

  • Robert McMahon

    Robert McMahon - 2021-03-01
    • status: accepted --> closed
     

Log in to post a comment.

Monday.com Logo