Lambchops,
Yes I think the game host has to contact the other players first (before they join the game) in order to open that inbound connection. However, the pvpgn server knows the IP of every player already, so what if a script was added to the client where the server sent the game host all IPs of the players, and the client reached out and contacted all the other players periodically to keep ports open to them
Something like that, I'm not really sure how it would work because the ports being opened by the game host to the other players would not be 6112? but if we spend some time learning how this problem has already been solved in other applications like VoIP then we can learn and understand how to hopefully apply it to PvPGN servers
Just look, I think theyve done it with Starcraft Remastered, it is possible I think
There's a discussion of the topic with lots of my thought on it
HERE The crux of the matter is:
So in this entire scheme there is only one point at which a UDP transaction is being attempted where one of the clients is 'blind', .i.e. it hasn't been pre-supplied with the other client's address and port. That is when someone first tries to join a game. The joining client obviously knows the host's address, but the host has no clue. Why? Maybe it was by design to reduce server load on the original battle.net servers, idk, but both clients already have an established TCP connection to the server. So why not?
All that needs to happen is: when a client attempts to join a game, it notifies the server (of course over the TCP), and the server in turn notifies the host of the joining client's address and port, which is 6 lousy bytes! (plus standard transport overhead). Then the host just has to send a few UDP packets out to the joining client. That's all.
The packets can be anything. Null packets would probably work fine, whatever, as long as it doesn't crash the client with garbage, its all good. We have then done our “lat trick” between the host and the joining client which is the only one not already being done. End of hosting issues forever. GG.
The idea of having the the server notify each host of ALL the players connected to the server - or in the channel (not just those attempting to join the game) would simplify the process slightly, but doesn't really lessen the required discovery/mods to impliment it.
This approach would probably work in the current environment simply because of the low numbers of players currently using the server but on any larger scale it would be definately inelegant and possibly infeasable to have the host's router constantly holding open entries in its routing table for every available player.
For an implimentation we would have to either:
(a) run it using the messaging system built in to the pvpgn server which already has a tcp connection to all clients.
or
(b) produce and deploy a seperate stand-alone server (could be run from server.war2.ru using an arbitrary unused port)
I much prefer option (a) being the far more elegant solution, although option (b) may possibly be slightly easier to get to a bootstrap level even though it's a bit like adding on a contraption made out of coat-hangers and gaffer-tape to what is already a convoluted enough system ... and if done properly option (a) doesnt need another server or even any mods to the pvpgn server.
----------------
To do this the way I envisage it we would need to identify and tap the procs that handle the /m messaging to and from the server to use them for notifying the host of the joining players, and also locate and monitor the proc that handles the whole [JOIN] game bit.
I have lately (last month or 2) been pushing to map out the exe in my spare time. All the stuff involving messaging strings I have found so far stores them in temporary stack buffers which are then instantly overwritten with other data as soon as they are displayed, so we would need to hook one of the procs involved in both the send and receive functions.
The host list is quite easy to pull from process memory but we would need to find the and hook the join proc to identify the appropriate game and notify the host.
With unlimited time and resources it's all very simple, but in real terms there's still a way to go yet, but each bit of the exe I discover and notate makes the next part a little bit clearer.... or if anyone else know's where any of these procs are in real terms, let me know and we can out our heads together.
the solutiom is "fuck U"
.... actually that one sounds much easier.... let's do that lol
