Am Sam, 2002-12-07 um 00.19 schrieb Alexandre Julliard:
Christoph Frick frick@SC-Networks.de Force (WS_)SO_REUSEADDR before binding to a socket;
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.
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.
ignore (WS_)SO_DONTROUTE; Network games in Grand Prix Legends and Nascar 2002 are possible now.
Footnote (i) in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win... says that this is - in principle - legal: "A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way."
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).
Alexandre, please back this patch out for now, at least the SO_REUSEADDR part which is plain wrong.
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.
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.
Martin
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!
Am Mon, 2002-12-09 um 14.57 schrieb Christoph Frick:
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.
Run with -debugmsg trace+winsock. You may also need to set DEBUG_SOCKADDR to 1 (look for it close to the top of socket.c), and recompile and reinstall the winsock DLL. Oh, and given the "NetTrans" thing below, run with "trace+reg", too.
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.
It is the "Service provider" which in this case is Microsoft TCP/IP (think of it as one of the "protocols" Windows allows you to install in the Network settings). Other service providers are IPX, NetBEUI, or Appletalk. Since TCP/IP is pretty important nowadays, if Microsoft TCP/IP ignores SO_DONTROUTE (actually, it seems to ignore the MSG_DONTROUTE flag to send(), too!) it is probably ignored almost everywhere in the MS world.
Wine's Winsock implementation is not (yet) modular - it doesn't use service providers.
Why i ask: please see my mail to wine-devel from 2002-10-25; the game also checks the .../NetTrans/... settings.
I am not sure what these are for. They seem to be Win95/98 specific - my Win2k box doesn't have them. It appears that for Win9x there should be one System/Services/Class/NetTrans/000x entry for each installed transport service provider.
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).
Well, browsing through MSDN, the reason may be past trouble with PCs with several network interfaces, where the game wanted to connect through a dial-up connection rather than through a LAN (or vice-versa). In any case it can't be much more than a hack some games were using to work around some obscure Win9x networking limitation.
Martin
-
Christoph Frick -
Martin Wilck