would it be possible to use the lat trick for multiple players? i've only ever tried in 1v1 .. But theoretically if ...........
...... you're talking about our ping in relation to the server.war2.ru.. what about /ping (specific player) .. the number shot back at me is the time it takes in milliseconds for our computers to communicate with eachother, correct? so, a player with a ping of 3500 vs 350 is going to make a noticable difference in game.....
so for the bonus question .. .....the only things i can come up with is somehow form a TCP connection (even if only temporarily) with all of the players on the server so you auto-send/recieve UDP traffic to those players after that .. or somehow, when you first log onto the server and successfully send/receive UDP packets to the server, have the server forward your UDP packets to all other players on the server so there is a "connection"........
Can't quite award full points for the bonus question, but I'm loving the way you're thinking. Definately asking the right questions. I'll write a post with my best answers to this next, But first, here's the answer I wrote yesterday.
... and everyone please note: This is all just theoretical. It seems to make sense to me, but I'm very happy for anyone to explain it to me correctly if any of this is wrong, that's why I started this topic.
....and for the extra bonus points... WHO WAS PAYING ATTENTION? - What small change could have been made to the battle.net protocol to eliminate the whole "opening ports" to host a game issue?
OK then, what do we know about this whole port forwarding lark? Sure, by rights you should have port 6112 (or another if you have configured a change) forwarded to your gaming computer's local address, so that the router knows where to send this traffic. Fine.
But we also know its pretty easy to get around, because even without this you can still join a game and have your client happily sending and receiving UDP packets to and from up to 7 other computers simultaneously. You can even host by using the “lat trick” to get around this.
Although I haven’t actually spelled it out, the reason you can join games is actually exactly the same mechanism as the “lat trick”. By virtue of everyone’s IP address and port being circulated to everyone else by the host, then everyone sending everyone else a UDP packet (and no doubt a few re-tries) over their game port, in effect the “lat trick” is just being done for you automatically for all players in the game.
So why can't you host then?
The problem is with that very first "I want to join" message that your client sends to the game host.
This goes back to the evolution of the game: the multiplayer game was designed to operate on a local network. The battle.net part, despite the nicely integrated graphics etc., is very much a completely different thing onto which they “bolted on” the existing multiplayer game like an after-market carburettor. The game list is little more than a very simple ad for the host's IP address and port, there isn't really any help beyond that. It's up to your client to try to connect to the host, but until it does the host doesn't know that the client is trying to connect
This is the big difference between hosting and joining, when you join you have already received the host's address from the server and sent outbound traffic when you asked the host if you could join. As mentioned, the host circulates everyone’s addresses so they can all send a few outbound packets to each other to initiate the transaction, and its all good.
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.
Want proof that your clients are actually doing the “lat trick” for you when you join a game? Try this:
(I've never tried it, but it should work;) /me quietly prays that it works...
When a game is over, but before you leave that game, pick somebody there who can't
host, (but has a good connection) to host the next game. Then decide on a nice easy game name, like “zz” or something. Then everyone leave at the same time. Have the next host (who can't host) immediately
host the game, and everyone else immediately type in “zz” and join. Don't worry about a password, anybody who wasn't in the previous game won't be able to join anyway.
Everyone should be able to join the next game, because the “lat trick” won't have timed out from the previous game. In fact this should
work from the pre-game lobby, without even starting the game (maybe all change race before you leave to be sure). I can't see why 4 players, none of whom can host shouldn't be able to decide on a host and a name then, for instance, all join the EF_gamebot game, then leave and have someone successfully host a game. *Of course all players would have to be in the gamebot lobby at the same time, you can't all join and leave one at a time...