The UNIX fd for a Windows socket is not even guaranteed to remain the same throughout a process's lifetime - shuffling fd's between the wineserver and the process changes their value every time. This problem also stops us from SOCKSifying applications running under Wine, because all SOCKSifiers out there assume fd's remain invariant. If you want to uniquely identify a socket despite fd changes, on (at least) Linux, you have to fstat() and consider the device ID/inode values IIRC.
On Sun, Sep 19, 2010 at 6:22 AM, Mike Kaplinskiy mike.kaplinskiy@gmail.com wrote:
Ah sorry, forgot to mention one more thing - fd's are different on the server side and the client side and between processes. So you're locking different semaphores everywhere effectively not locking anything.
Mike.
On Sat, Sep 18, 2010 at 11:59 PM, Mike Kaplinskiy mike.kaplinskiy@gmail.com wrote:
A few broad comments: - There's enough #ifdef's to make this mostly unreadable. It's hard to think of the cases of no IP_PKTINFO availability, only compile time availability or full availability. Please just write a few wrapper functions for the #ifdef's that return sensible values if IP_PKTINFO is not available and then use them. I understand that in some places (i.e. WS2_send/WS2_recv) are supposed to be #ifdef'y but it may be easier to comment if you minimize the sheer number of combinations. - Pick a place to do the filtering and stick with it. You do some filtering in the server, some filtering in wine-userspace and some calls aren't filtered at all (see blocking recv's). I would suggest forwarding ReadFile/WriteFile to WSARecv/WSASend for sockets and then taking care of it in ws2_32 (we might end up needing this soon anyway for other annoying reasons). Even if your async reads are woken, you should be lenient enough in WS2_recv to return EWOULDBLOCK if no packets matching the interface are available. Since you don't do this now blocking recv's are broken. Also, FYI our *nix sockets are always non-blocking, you don't need MSG_DONTWAIT. - So what if an application likes to bind to an interface AND use IP_PKTINFO? - I don't think this is the right approach. Alexandre's comments from last year still apply. We would have to change the way we do sockets entirely; instead of just passing through to similar functions in *nix we would need to emulate a network stack (which is really what your patches crudely do). For example, now we wouldn't be able to use poll anywhere reliably on sockets. I don't think that's a direction Alexandre wants to go in. I think only one of two things will help us in this case - the kernel folks appease us or wineserver becomes a kernel module and we just do I/O from wineserver. Both of which are on schedule for around the time hell freezes over. - If you really want to get this to work consider writing something to LD_PRELOAD that emulates most of the network syscalls (+ read) with windows-style bind'ing correctly. I'd argue this may be easier and faster than putting the fix it into wine. This may be more user-friendly than having people compile wine themselves.
Mike.
On Sat, Sep 18, 2010 at 10:44 PM, Erich Hoover ehoover@mines.edu wrote:
I realize it's been some time since I've submitted something for the networking problems with the C&C games, but I believe I've come up with something that resolves the major show-stopping issue that was discussed previously. Here is the original thread, for reference: http://www.winehq.org/pipermail/wine-devel/2009-October/079099.html
Specifically, this set of patches is revised to address the problem of throwing away packets destined for the incorrect interface in a multi-threaded/multi-process environment. The approach used here is to create a global (named) POSIX.1-2001 semaphore for each socket with the form wine-ifacelock-FD , where "FD" is the Unix file descriptor corresponding to the socket at hand. These semaphores are only created for UDP sockets bound to a specific interface and are locked/unlocked by both the Wine user-space and the Wine server.
These patches are against wine-1.3.3 and are split apart according to function. The most revised portions since the original set are 2/6 (server-side creation of semaphore), 3/6 (locking and unlocking), and 6/6 (server-side locking and unlocking). If I could get some feedback on these patches then I would greatly appreciate it, it'd be really nice to finally get this issue resolved. Thanks in advance!
[1/6] ws2_32/tests: Add UDP broadcast tests: http://www.compholio.com/wine-kane/patches/2010-09-18/0001-ws2_32-tests-Add-... [2/6] server: Add mechanism for storing an interface ID with a socket: http://www.compholio.com/wine-kane/patches/2010-09-18/0002-server-Add-mechan... [3/6] ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets: http://www.compholio.com/wine-kane/patches/2010-09-18/0003-ws2_32-Patch-to-s... [4/6] ws2_32: Ensure select does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0004-ws2_32-Ensure-sel... [5/6] ws2_32: Ensure Async WSARecv does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0005-ws2_32-Ensure-Asy... [6/6] server: Ensure Async ReadFile does not wake up on packets with an interface mismatch: http://www.compholio.com/wine-kane/patches/2010-09-18/0006-server-Ensure-Asy...
Erich Hoover ehoover@mines.edu