[Bug 50955] .netCore app can't bind to port shortly after another .netCore program binding to the same port was terminated

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50955

--- Comment #6 from florian.will at gmail.com ---
Created attachment 71910
  --> https://bugs.winehq.org/attachment.cgi?id=71910
Patch for this bug

This patch should fix at least the "after a program binding to the same port
was terminated" issue (that is, this bug report).

When a process is terminated and still has connected sockets, this patch makes
sure to abort these connections (TCP RST) instead of the normal FIN/ACK
sequence through shutdown(). This matches Windows behavior and it skips the
TIME_WAIT state, so hopefully it fixes the BrokenClient/BrokenServer? I don't
have a c# development environment set up so I can't test. Bernhard, do you
still have your test case ready and could give it a try? It does fix the
ZusiDisplay issue for me, at least the one time I tried it.

(I also had to change the sock_dispatch_asyncs function to wake up pending
asyncs in case of connection abort, otherwise blocking recv() calls would still
hang/block after the connection was reset and seemingly never return. Is this
another bug, or am I misusing something in wineserver?)

This patch does not fix the general "Windows appears to allow listening on a
port even though some old connection using that port is still in TIME_WAIT, but
Linux refuses to do that" issue, but it's good enough for me.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.