The forum

Let's say I want to play a game which allows only one client per ip.

One way to circumvent it is to create a network namespace and use it to connect to an outside vpn, so I got IP1 & IP2

let's say now I have a virtual drive in POL named drive1 and another named drive2

in drive1 i got program1.exe and program2.exe where program1 and program2 are copies.

in drive 2 i got program2.exe

• drive1
  • program1
  • program2
• drive2
  • program2

the goal is to have program1 connecting with IP1, and program2 connecting with IP2.

If I run POL normally and launch program1 in drive1 I connect using IP1, normal and intended.

then I launch POI in the network namespace: so any app I run in that POI instance should have IP2, that was my understanding.

What I found is that if I run program2 in drive1 I still have IP1, while if I run program2 in drive2 I have IP2.

is that normal ?

 

Hi,

I didn't knew about network namespaces, I went read about it, but it's fresh knowledge for me, so I could be talking BS. Another reason for being wrong is that while I'm a quite familiar with Wine now, I don't know all its internals, so I could be wrong in my interpretation there too. Feel free to correct me guys. Anyway.

When you run a program under Wine, there's actually two processes running: the one started by "wine", which emulates windows address space, loads different DLLs including low level ones, and ultimately the program you requested, giving it an expected environment to run in; Then there's the wineserver process, that handles all the "state", and all the resources shared by all the programs running in the same Wine environment.

The former need the latter to run, and if it can't find a wineserver running for the environment (a "wineprefix") it's started in, it'll spawn a new one; Otherwise, it'll just communicate with the existing one. The wineserver process will stay around as long as they're "client" programs connected to it (and usually a few seconds more, see wineserver -p)

In PlayOnLinux, we create one such wineprefix for each managed virtual drive (hence we often say virtual drive when we really mean wineprefix, it's easier to explain even if not 100% technically accurate). Anyway, that means that in your example you can expect one wineserver process for programs run from drive1, and one wineserver process for programs run from drive2.

 

I think that most (if not all?) network APIs are actually implemented in wineserver, so when a program does network calls, it's actually delegating the task to the wineserver process, and this explains what you're observing:

When you run program1 from drive1 in the first PoL instance, it spawns a wineserver for drive1; Then when you run program2 from drive1 in the second "network nameserver bound" PoL instance, it'll communicate to the same wineserver instance, also delegating its network calls to it, bypassing its assigned network nameserver...

 

that makes a lot of sense, seems like it's all about launching programs with a separate wineprefix per network namespace

 

thanks for the explanation