wine/dlls/winsock/socket.c: Force SO_REUSEADDR on before bind()/Ignore SO_DONTROUTE

Christoph Frick frick at SC-Networks.de
Mon Dec 9 07:57:22 CST 2002


On 9 Dec 2002, Martin Wilck wrote:

Hi Martin, All

> Sorry, this is definitely wrong. Windows, just as Unix, returns
> WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There
> must be some special circumstances involved in those games the patch is
> supposed to fix. Perhaps they assume a certain Winsock implementation or
> Windows version.

yeah i am sure there are. also the dontroute stuff is a 100% evil hack. At
least i got this time some attention :)

About the games: GPL is from 1998 and N2002 is from 2001/2002. They suffer
both from the same problem - i guess they expect a behavior not a version.

> I'd like to know what remote addresses exactly the apps call bind() for,
> and in what order. Perhaps there are subtle differences in the way
> EADDRINUSE and SO_REUSEADDR are handled.

I can basically describe you what this games do network-wise and/or i can
provide you with traces (with and without patch) - what do you prefer? What i
can not do is testing in windows.

> However the patch implements the first behavior (ignore) whereas 
> the Windows TCP/IP transport behaves as the second (later calls to
> getsockopt() refelect the SO_DONTROUTE settings, which seems to have no
> further effect).

So closer to windows would be store and ignore. In general i wonder, if
windows does this always or if this depends somehow on the "device" the socket
is finally bound to - or in other words: is always the same code on windows in
charge or could it be that this might be implemened e.g. by a NIC driver.

Why i ask: please see my mail to wine-devel from 2002-10-25; the game also
checks the .../NetTrans/... settings. Maybe here is something missing that
tell the game to set SO_DONTROUTE. Wine does not set them automatically like
other hardware/driver related stuff. I really can not imagine, why a game
should set this option explicit when it connects to an server (the ip/name is
entered manually in this case, so the game should expect the host not in the
same network).

> Please don't get me wrong: These issues need to be fixed, but please,
> not by applying hackish patches for special applications such as this
> one.

I think 100% the same way here. 

> Christoph: sorry I missed out on your previous mails to wine-devel. 
> Next time, say something about sockets in the subject line and chances
> are I won't miss them again.

Yes you are right. At least the last mail had no single word about the network
issues with this games in the subject. I will try to focus more on the real
problem next time.

Thanx for your reply

CU!




More information about the wine-devel mailing list