Warcraft II Forum
Warcraft II => Server.War2.ru => Topic started by: Lambchops on October 17, 2016, 03:19:40 PM
-
So the server is lagging a bit at the moment. Sounds like a good time to talk about general lag issues.
Here's what I know about the way WC2 and battle.net worked 15 years ago... we're now using a PvPGN server and an AH server also, so things could be different now. If I'm wrong about any of this stuff, please reply and add your info.... but AFAIK it's like this:
First there's 2 types of network traffic you need to know about:
(don't worry it's really not that technical...)
UDP: (https://en.wikipedia.org/wiki/User_Datagram_Protocol) User Datagram Protocol
and
TCP: (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) Transmission Control Protocol
The difference is this:
- TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) makes a connection between 2 computers, in this case a player's computer and the server. Once a TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection has been made, the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) protocol guarantees that every message either of them sends to the other is successful. It checks, and if there's a problem, the message is sent again, until it goes through, or eventually the connection is abandoned, whereupon both ends will be notified that the connection has failed.
On the other hand..
- UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) does not do this at all. If one computer sends a UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packet to another, it has no idea if the other computer receives it or not. Some program running on the other computer can send back a message confirming the packet arrived, if it wants, but that is not part of the UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) protocol (whereas it is built into TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol)).
There's also another 2 terms I'm going to use a bit which are:
IPX: (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange) Internetwork Packet Exchange
and
IP: (https://en.wikipedia.org/wiki/Internet_Protocol) Internet Protocol
- IPX (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange) is just an old network protocol that is no longer used. Although internally different, as far as the descriptions above go, IPX (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange) can be considered the same as UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol). It was popular in the late 80's and early 90's but by '96 it was on the way out and was not widely supported after that.
- IP (https://en.wikipedia.org/wiki/Internet_Protocol) is the basis of the internet. It's that base layer that is sending packets from one "IP Address" to another. You have probably heard the term "TCP/IP" before, well this is the "IP" part. By this terminology the UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) traffic could be called "UDP/IP" because the "IP" protocol is operating beneath both of them. Often these days people say "IP" when referring to an IP Address (https://en.wikipedia.org/wiki/IP_address), however here I'm talking about the protocol itself. When I'm talking about an IP address (https://en.wikipedia.org/wiki/IP_address) I say "address".
So... going back to 1996 and Warcraft II:Tides of Darkness (https://en.wikipedia.org/wiki/Warcraft_II:_Tides_of_Darkness) when the internet was still in it's infancy, the guys at Blizzard used a network protocol they were familiar with to implement the pre-battle.net multiplayer games. That was IPX (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange). For those of you old enough to remember Kali (https://en.wikipedia.org/wiki/Kali_(software)) this is where that fits in. Kali is an IPX (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange) emulator, so it allowed people to play multiplayer games based on the old IPX (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange) protocol on that new wonder of the modern age "The Internet!".
But the point is this: the networking side of the game engine has remained pretty much unchanged from 1996. When Blizzard released Warcraft II:Battle.net Edition (https://en.wikipedia.org/wiki/Warcraft II:Battle.net Edition) in 1999, they included all sorts of cool new stuff related to battle.net: server channels, messaging, friend lists etc.., and of course the most important thing - the ability to make a game or join a game. All these battle.net features worked over a TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection. This connection is established when you logon to battle.net and (being TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol)) it maintains itself, and guarantees the integrity of all messages passed through it.... for example unless the connection fails and one of you is actually dis-connected from the server, a /m to another player NEVER fails, even with bad lag it will still go through eventually.
If you make a game, your client (wc2 program) will talk to the server over this TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection and tell it the name of your game and other details. If click the JOIN button the server will talk to your client over this TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection and give it a list of games. This list includes the game name, the pud, the settings, and most importantly the IP address (https://en.wikipedia.org/wiki/IP_address) of the host.
It is at THIS point in the process that battle.net ceases to be part of the equation. When you join a game, the internals, for the most part are still exactly the same as they were in 1996, the only difference is that instead of using the old IPX protocol, which was not supported by the internet, BNE substituted the UDP protocol, which was supported. This, however is just wrapping your sandwich in cling-wrap instead of tin-foil, its still a BLT inside. When you join a game (or try to!) you start sending peer-to-peer UPD packets the host's client, which then sends you a list of addresses for the other clients already in the game, and sends your address to them. To successfully join your client needs to make UPD "connections" to all of the other clients in the game.
I say "connections" in quotes, because of course UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) (or IPX) does not make connections it just blindly sends packets and hopes they arrive. Your client (the wc2 program) IS, of course keeping track of what packets arrive, and if one connection is losing packets you will see it on the lag screen, or as we know if YOU are the person with the bad connection you will often see several or all of the other players listed on the lag screen, because from your client's point of view packets are missing from lots of other clients.
So this is how WC2 games work over a network, with all of the clients all firing UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packets at each other. So what about the server? Well you trusty TCP connection to the server remains in place, but this connection does not have anything to do with the game. It can't cause game lag. The only thing that can cause game lag is problems with the UDP traffic between the clients.
The BNE client knows to send any chat that starts with a "/" to the server over this TCP connection and the server will then process that message or reply with a WTF? and your client will say "Unknown Command". If the server is lagging it can take 5 or even 10 seconds to get a response. Can you imagine if it took 5 or 10 seconds for every update in the game? There's just no way.... that would be beyond bad lag. Generally speaking for a game not to have annoying lag, the clients needs to update each other every 1 second or so, ideally much less. That means every client needs to be able to send and receive a UPD packet to/from every other client no later than once a second.
BUT, the clients do not, as part of the game send any UPD packets to or receive any UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packets from the server. The only time this happens is when you first login to the server, it does a check to see if you can send/receive UDP packets over port 6112. The reason this will usually succeed even though you may still be unable to host is to do with the way your networking infrastructure (modem/router/network card/drivers etc.) handles traffic. In short, once the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection is established with the server, the underlying IP (https://en.wikipedia.org/wiki/Internet_protocol_suite) "Internet Protocol" automatically sends any traffic from the server to the client at the other end of the connection, regardless of if it is TCP, UDP or whatever.
This is how the "lat trick" works if you haven’t got your game port properly routed. You have a TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection to the server, which gives you the IP (https://en.wikipedia.org/wiki/Internet_Protocol) address of the host. So your client sends a UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packet to the host saying "I want to join", but at this point you there hasn't been any communication whatsoever between the two clients. Any channel chat or /m messaging is relayed through the server, so if the game host hasn't got the game port "opened" (properly routed to the client) then when a random UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packet turns up from some random client, the IP (https://en.wikipedia.org/wiki/Internet_Protocol) has no idea what to do with it. But if you alternately make games, then try to join each others' games, you can train the IP (https://en.wikipedia.org/wiki/Internet_Protocol) running in your hardware to associate traffic over that port with a certain IP (https://en.wikipedia.org/wiki/Internet_Protocol) address.
But if you can't get UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packets through to the server when you log in it will give you a warning message saying you won't be able to join games. It will, however still let you log in and chat/message/see the game list etc... everything that happens over the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection. If you join like this you will have the grey "bot" icon which has an unplugged power cord on it.
So back to joining a game. Why can you join a game even if you haven’t got your game port properly routed? Why is it just when you host? This is all IP (https://en.wikipedia.org/wiki/Internet_Protocol) layer stuff, like the "lat trick" above. The problem is with that very first "I want to join" message that your client sends to the game host. If the host's game port isn't routed to the correct end-point then this message turns up from an unknown address on an un-defined port, and the IP (https://en.wikipedia.org/wiki/Internet_Protocol) routing (quite rightly - or you would be vulnerable to all sorts of attack) discards the packet. However, if the host has already said "send me all the packets on port 6112 (or whatever port) then the packet is forwarded to the host's computer, where the wc2 program already has a socket open listening for UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) traffic on port 6112.
Once that first message has gone through, the host gives the client a list of addresses for the other clients in the game, and also gives all those other clients the address of the new client joining, and everyone starts sending UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) packets at everyone else.... and once you have sent an outbound packet over given port to a given address, the IP (https://en.wikipedia.org/wiki/Internet_Protocol) accepts that your client machine is exchanging data over that port with that external address, so it thereafter routes all incoming traffic to that client.
But, friends and fiends, no amount of server "lag" will make your game lag.... nope, sorry... and here's the proof: what happens when the server crashes during a game? You get a message saying "connection to battle.net lost". This is the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection timing out. As we know TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connections are "guaranteed" by the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) protocol. It is internally sending back and forth packets to keep the connection alive and verify that any communication has reached its destination, until your client fails to receive any response from the server for a pre-defined amount of time, when your TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) drivers give up and notify the client that the connection has been broken.
But when this happens does the game end? No, because the server isn't part of the game, once a game has started you could blow up the server with an RPG (https://en.wikipedia.org/wiki/Rocket-propelled_grenade) and it wouldn't stop the game. It stops any messaging etc., any command starting with a "/" but the game continues. When the game ends, even if the server is back up and running you don't go back to the channel, you are back in the pre-connection part of WC2, because the wc2 client wasn't written to automatically attempt to re-establish a TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) connection with the server (this is inherently unsafe as it would have to be storing and re-transmitting your password without your knowledge).
So if there is server lag, it can be slowing down/lagging all the stuff that involves the server: logging in, chatting, messaging, your friend list, getting the game list etc., but it doesn't lag games. Perhaps in theory if there is server lag the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) service is generating a little bit more network traffic saying "hello? can you hear me?" a bit more often, but if your network is operating on such a tiny amount of bandwidth that it would even notice this then I would expect that you would already be having all sorts of problems.
So what causes lag? Lag,(or lack of it) is a function of the peer-to-peer UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) times... or more to the point the worst peer-to-peer route between any two players in the game. There are 2 factors in "worst". Obviously speed is one, but even worse is actual packet loss, where a packet is sent from one place and and just never turns up at its destination. A crackly phone line can do this - or a recalcitrant server (not the game server - just some random internet server). This sort of thing is what causes "conflicts" between two players, that otherwise tend not to have problems. This is because *somewhere* in-between those two end-points is a server that is not doing the right thing with UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) traffic... or perhaps with all traffic to/from certain locations ... or maybe it's just plain overloaded.
So while we're on the subject, what's with "/ping"?
The "/ping" or "/p" command is not a battle.net command, it's one of the extra features built into PvPGN (that's the software that runs the war2.ru server - it's a battle.net emulator). "Ping" is a basic networking feature which just sends a packet from one computer to another which asks the remote computer to send it back. The "ping" time is the time it takes for the message to go to the remote location, get processed, and return to where it came from. Usually this is repeated a number of times and an average time is reported.
As we know, when you first login to the server, your /ping will be reported as "0". It appears that checking client ping times is either averaged out over number of checks over a reasonably long period of time, or (more likely) it is a task that the server deems to be low priority and schedules it to be done some time when it is twiddling it's thumbs with nothing better to do. So you wait a few minutes and the server reports a time in milliseconds. Try this for fun: on windows go start-->run then type in "cmd"[ENTER]. This will bring up a DOS style command prompt. Then type "ping google.com"[ENTER]. You can do the same thing from a UNIX machine.
The ping reported by the "/ping" command is the round-trip time from server.war2.ru to your client and back again. It does not necessarily have anything at all to do with game lag, although an excessively high number here can be indicative of a network issue. But as we know, lag is related to peer-to-peer UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) times, connection time to the server has nothing to do with it... although if you have a really slow connection you will also have a high server ping time, but a high server ping time does not necessarily mean you have a slow connection.
Another interesting thing here is that right now, when the server is having some genuine lag issues it is reporting my /ping as 247. This is extremely low for me (being in AUS). Normally my /ping is reported at 500+. It's just conjecture, but it could be the result of the server's host provider throttling TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) traffic. As pinging is a "control message", operating on the ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol) protocol - which is usually prioritised by servers, if the connection is being throttled at the TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) layer, it could leave other IP (https://en.wikipedia.org/wiki/Internet_Protocol) layer traffic with extra bandwidth, hence faster ping times... or maybe they just switched to a host in AUS?...nah lol.
(((EDIT: more likely by the time I wrote this much, iL had already fixed the server issues so it was all nice and speedy, but at the time I assumed it was still having issues, as I was writing not playing)))
So what's with the green/yellow/red bars on the game list and next to each player when you join a game? These are ping times, but are very different ping times. The bars in the game list is the ping time between the host and the server. When you join a game and are waiting - before it starts, as we know, at this stage it's all about peer-to-peer UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol) traffic, so those bars are the ping time between you and that other player. If you see one player go red and the rest stay green, its probably their problem. If you see all players suddenly go red, kick your GF off facebook ;)
IS ANY OF THIS WRONG?....or does some part of it just seem wrong?.... post a reply and tell me what you think!
....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? ? ? I'll post the answer to that later when everyone has just said "FFS, doesn't that nerd ever shut up?" and completely ignored this post.
-
What is the logic behind "conflicts?" There's a game up and either Player A or Player B can join the game and it doesn't lag, but if both are in, it does.
What is the logic behind the lat trick? Two people who do not have port forwarding set up can still host a 1v1 with each other. Player A hosts, Player B tries to join but cant. Then Player B hosts and as long as Player B tried to join A's game, A will be able to join B's game.
Hopefully you know, always was curious about these two things.
-
What is the logic behind the lat trick? Two people who do not have port forwarding set up can still host a 1v1 with each other.
The info is all there .. but it's a bit scattered (like me;) so...
With regard to lat trick:
once you have sent an outbound packet over given port to a given address, the IP accepts that your client machine is exchanging data over that port with that external address, so it thereafter routes all incoming traffic to that client.
When you try to join a game, the server supplies the host's IP Address and port, then your client tries to send a UDP datagram to the host but...
The problem is with that very first "I want to join" message that your client sends to the game host. If the host's game port isn't routed to the correct end-point then this message turns up from an unknown address on an un-defined port, and the IP routing (quite rightly - or you would be vulnerable to all sorts of attack) discards the packet. However, if the host has already said "send me all the packets on port 6112 (or whatever port) then the packet is forwarded to the host's computer
So player A is hosting and player B tries to join. At this point you have player B has sent an outgoing UDP datagram to A, but A's routing just says "WTF is a 6112??" bugger that.
Then the positions are reversed so then player A is sending outgoing UDP on port 6112 to player B, and B has already sent one the same to A so at this point player B's IP routing could say "ok then i'll send that to (player B's computer's local IP address) because we have already sent one of those out to that other address". It may take a few goes back and forth depending on the actual logic in your router's firmware.
The thing is that routers are not designed to just blindly forward everything that the outside world throws at them to your computer... you can tell them to if you want, this is called DMZ ("de-millitirized zone"), but you still have to tell the router which computer is the DMZ, because, and this is the other point, they are also not designed to have only one computer attached to them... but really you just want to tell it to send you port 6112 traffic, not ALL trafic. The underpinning logic of the internet, and therefore the internet protocol is that any router can get a packet intended for any address and send it in the right direction to get there... and the next router (server... whatever) will do the same, until the packet eventually gets where its going.
When you use your browser to pull a web address, your browser initiates a TCP connection with the remote server (over port 80 for plain http). Because this connection started at your computer and went out, and the connection is maintained by the TCP protocol, your router automatically sends back the server's reply over this already established connection that your computer started.
When somebody tries to join a game you have hosted, they send a UDP packet to your external IP Address, there could be any number of devices connected to your router, or being something that originated externally, it could be malicious, it is an unknown, and without specific instructions, like "send all udp traffic on port 6112 to local IP address 192.168.0.4" (this is forwarding the port) it will just discard the packet.
With the "lat trick" you are manually forcing each client to send UDP traffic to each other over a certian port and simulating a "transaction" like a TCP connection, which "tricks" or "trains" (depending on how you look at it) the IP layer into forwarding the traffic to the desired endpoint.
Hope this was a bit more understandable.... I'll do a seperate post on conflict
-
BTW: about current problem with lagging: if i understood properly, the problem was related to long /commands handling. When you type /w or /con or /p or w/e.
That was not related to any network problems. The problem happened with database connection. That is about that php extension for pvpgn. I just removed that database connections from handlers now and that delay is gone.
P.S: Lambchops, nice to see such detailed and interesting posts about network connections, i think that will be useful to community. Would be interesting to read your post about conflict also.
-
Good post. Actually read the whole thing because it was interesting.
-
BTW: about current problem with lagging: if i understood properly, the problem was related to long /commands handling. When you type /w or /con or /p or w/e.
That was not related to any network problems. The problem happened with database connection. That is about that php extension for pvpgn. I just removed that database connections from handlers now and that delay is gone.
FYI - I see this type of server lag all the time. For example, /f l, right now it's instant. Most days, it's like a 2-3 second delay before the list shows up.
-
What is the logic behind "conflicts?" There's a game up and either Player A or Player B can join the game and it doesn't lag, but if both are in, it does.
Lag,(or lack of it) is a function of the peer-to-peer UDP times... or more to the point the worst peer-to-peer route between any two players in the game
The server is not part of the game. All clients talk directly to all other clients. If you have a 2v2 game: A and B vs. C and D. then A and B talk to each other.... but A and C also talk to each other .... and A<-->D and B<-->C and B<-->D and C<--->D ..... (did I leave anyone out?) .... so they ALL talk directly to each other.
OK so then we factor in what I was saying about routing in the lat trick post above:
The underpinning logic of the internet, and therefore the internet protocol is that any router can get a packet intended for any address and send it in the right direction to get there... and the next router (server... whatever) will do the same, until the packet eventually gets where its going.
The routing tables in most home routers are pretty simple, they mainly just say "anything that isnt a local address send HERE" with "local address" being defined as whatever your local network is (often 192.168.X.Y or 10.0.0.X combined with a sub-net mask ) and "HERE" being the gateway address supplied by your ISP, which is whatever the IP address is of their server that they are selling you access to....
When you get to your ISP's server it has its own routing table which may or may not just forward everything to a central node, but at some point there will be a bunch of rules like "everything from 0.x.x.x to 127.x.x.x send to server A" and "everything from 128.x.x.x to 255.x.x.x send to server B" ... this is a simple example, there will most likely be a heap more routing rules than that. And those servers will have their own routing tables which will define, for them, the quickest way to send all packets based on their IP addresses... these can also change dynamically depending on what time of day it is and how much load various other servers are under. And of course these servers will have rules telling them to send packets with YOUR ip address back to your ISP's server, which then forwards them to you.
Everybody forwards everybody's traffic... and everybody sends it via whatever route is defined in their routing tables .... in theory this is the "fastest route from A to B" but there may be a variety of other factors at play, i.e. social/political/monetary... who knows? All you know is that you send the info to your ISP, it picks another server to forward it to, which in turn forwards it to another ... etc., until it reaches the destination.... You can check this out on one of the "Ip tools" type websites that does a "traceroute".... this will show you the list of servers that form the link between you and another given server.
SO... back to our 2x2 game... so say, for example, player A is in AUS, player B is in GBR, player C is in USA and player D is in UKR.... perhaps player A can talk to B,C and D fine, same for player B, in fact everyone can talk to everyone else, EXCEPT... somewhere between player C and player D, one of the servers chooses to route the traffic through some shit-box old crappy server in Iceland because they don't pay as much tax that way (or WTF ever). It may even be in one direction only i.e. D can send traffic to C very fast, but when C sends traffic to D there's a problem... (you remember that "ping" times are round trip times so a problem in either direction will show up) ... maybe the guy programming the routers in Iceland was married to a Ukrainian and she ran off with the guy next door, so he said,"screw you and yours" and downgraded all traffic to UKR to the lowest possible priority.... who knows....
Of course these things aren't as simple as that example... it's more likely to do with rival companies downgrading each others' traffic... or a combination of all sorts of things... but the point remains that what causes lag is the speed and reliability of round trip UDP data between all players, and the actual route that the data goes through from player A->B is different from A->C, in fact it may even be different from B->A and all it takes is one crappy or overloaded server to be the "weakest link in the chain" and cause a crappy connection. When it happens that by virtue of whatever happens to be written in the routing tables of a bunch of servers wherever in the world, that one or more of these weak links ends up in the route that data is sent from one player to another, those two players will "conflict".
It may be only between two specific players, but from what I have seen, certian players seem to have problematic connections and will tend to conflict with a few people. One way to fix this *COULD* be to change the route by using a fast proxy or VPN. A VPN establishes a connection over HTTPS between the client and the VPN provider, from where the data would most likely be routed through a different set of servers to the other players. Many servers give priority to this type of traffic so it could even end up being a faster connection, ..... or bloody aweful lol, its a matter of experimenting to find what works
-
good post. im stoned right now but i'll re-read again and i'm sure it'll be even better ;)
-
BTW: about current problem with lagging: if i understood properly, the problem was related to long /commands handling. When you type /w or /con or /p or w/e.
That was not related to any network problems. The problem happened with database connection. That is about that php extension for pvpgn. I just removed that database connections from handlers now and that delay is gone.
Nice one :D
....and thanks for donating your time and expetise to maintaining the server for us. I for one appreciate it.... I'm sure you have a job and a family and pleanty of other demands on your time.
Good post. Actually read the whole thing because it was interesting.
P.S: Lambchops, nice to see such detailed and interesting posts about network connections, i think that will be useful to community. Would be interesting to read your post about conflict also.
good post. im stoned right now but i'll re-read again and i'm sure it'll be even better ;)
Thanks, for the feedback guys (and your questions Sentinel1), I'm glad you found it useful. :)
I've been meaning to write something about this for a while... just to clear up a few misconceptions about a bloody awesome server that is provided for free by people who do it for no more than the love of the game.
Love your work beautiful people :)
-
You can check this out on one of the "Ip tools" type websites that does a "traceroute".... this will show you the list of servers that form the link between you and another given server.
One thing that should be mentioned here is that this will show you the route that the servers process "traceroute" packets through, but this is not necessarily the route that they send TCP port:80 traffic through, let alone UDP port:6112 traffic. Maybe it is.... maybe it isn't. But I can give you a very good example of this kind of "selective" routing, being that if I log on to an "ISP speed testing" type website I will get absolutely phenominal speeds and its will tell me that I have a fully awesome connection, when I know very well that in reality my connection is hard limited at about 20% of that speed downstream, and a whole lot less again upstream.
I can see only two possible explainations for this:
1) The people who designed all the major speed testing sites can't do simple arithmetic.
2) My ISP knows excatly what the addresses of all the major speed testing sites are, and gives maximum priority and bandwidth to all speed testing packets being sent to and from these addresses....
I'll let you decide which is more likely ;)
-
....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?
Awww c'mon…. Anybody? Pls tell me somebody is picking up what I'm putting down….
( peeps with a pre-existing obligation not to discuss the internals are excused )
-
I'm at work now.. gonna re-read when home and sober and take a stable at it :)
-
I'm at work now.. gonna re-read when home and sober and take a stable at it :)
go hard mr khan :)
-
as im reading ... would it be possible to use the lat trick for multiple players? i've only ever tried in 1v1 .. But theoretically if you have 4 players, each one of them unable to host/join eachother's game, they could all do the lat trick individually to eachother, and as long as all of the players attempted to send/receive UDP packets individually to each player, you should be able to eventually get all 4 of them in the same game, no?
Also when you're talking about /ping .. 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 .. small change to protocol to eliminate need to open ports. and im just going to take a huge shot in the dark because even after reading all of it, im by no means an expert in any of it ;)
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" made between you and all of the other players as soon as you log on... but im not sure if the 2nd would be possible since the forwarded UDP packets would be coming from the server IP address, and not your own.
-
there definitely needs to be a connection made some how between the two players as soon as you log on.. either TCP or if you could have the server forward UDP packets from one player to another and visa versa so both players recognized eachother. those are my guesses.
-
i got impatient and looked into it myself... i think i was kinda on the right track:
Skype made a technique popular that is called firewall hole punching: A server with a public address is contacted by the clients. Then it sends an answer back to client A telling it to send udp packages to the router of client B on a port it expect the router of client B to use as source port for the next outbound packet. And it tells client B to send a packet to the router to client A on a port it expects the router of A to use as source port for its next outbound packet. If the prediction is correct, A and B can now talk directly which each other.
-
One way to fix this *COULD* be to change the route by using a fast proxy or VPN. A VPN establishes a connection over HTTPS between the client and the VPN provider, from where the data would most likely be routed through a different set of servers to the other players.
Interesting if that's posible to make something like NAT substitution for such problem clients. I mean some kind of wrapper between war2 client and network adatper. Say, the problem is between 1.1.1.1 and 2.2.2.2. War2 from 1.1.1.1 sends UDP to 2.2.2.2, that wrapper translates 2.2.2.2 to 3.3.3.3 (another client which connections to 1.1.1.1 and 2.2.2.2 are faster) like kind of vpn. 3.3.3.3 translates traffic back to 1.1.1.1 after receiving answer from 2.2.2.2.
Such kind of distributed UDP antilag-network. With dynamic scanning network performance between each pair of clients and finding the best routes.
Such solutions should be implemented somewhere already. Would be great to get such opensource solution and use for our tasks.
as im reading ... would it be possible to use the lat trick for multiple players?
Also good question. I'm pretty sure it's possible with some kind of software (like loader), every client just sends UDP packet to any other clients.
And yes, some new and popular software products (like skype) have such solutions integrated into it.
Appreciate if someone can offer some libraries for keeping UDP interchange between clients or w/e to integrate into C++ project.
-
http://gamedev.stackexchange.com/questions/9971/networking-without-port-forwarding (http://gamedev.stackexchange.com/questions/9971/networking-without-port-forwarding)
This is where I found out the firewall hole punch trick
-
Based on the way it was explained, I would imagine the lat trick would work for multiple people without additional software..
4 players. A B C D
A hosts. B c d try to join (all sending upd packets to A) .. none join.
B Hosts. A c d try to join, only A would get in because at this point player A and B have both sent udp packets to eachother.
C hosts and all try to join. this time both player A and B are able to join.. D is left out because he has only sent udp packets, nobody has tried to send him anybyet.
Once D hosts.. all should be able to join.
Long process, but should work, no?
-
The only reason I can see it wouldn't work is if player D (or maybe C also) has disregarded packets being sent to it from player A since there were a series of packets being sent previously, with no immediate response back
-
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"........
Cool. 8) 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...
-
When I initially answered I did not realize the server could request player A to send a udp packet to player B and visa versa .. I did see a flaw in the answer I gave (or what I believed to be a flaw) .. if the server were to try to simply forward UDP packets from player A to player B, player B would see those packets being sent from the servers ip address, not player A's ... unless there was some kind of mechanism that was able to trick player B into believing the packets were directly sent from player A and visa versa
-
.. 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
My understanding of the PvPGN '/ping' command is this: It periodically pings each connected client and keeps a record of the result. In the channel /p will return the last recorded ping time for yourself, in a game it will list the last recorded time for each player in the game, and /p (player) returns the last recorded time for that player. They are all accessing the same info which is the roundtrip -server--> player--> server- time.
The server can't give you a ping time between two clients. The ping has to come from one of the endpoints you are testing (i.e. your computer). Any line starting with '/' is sent to the server, so for this to happen the server would have to send back a request to your wc2 asking it to ping another player then display the results. PvPGN is a generic battle.net emulator and not in any way specific to wc2, and this type of ping display isn't built into wc2, so without mods to the client this can't happen.
But they way you're thinking is right, its all about the connections between each client. Where you DO see this is the 1G --> 6R bars next to each player in the pre-game lobby. But in reality the raw ping time is not the most important factor; you rarely see anyone with anything more that a 3y ping managing to join a game, and they can be fine with regards to lag. What you do see is people's connections going 6R periodically etc. A stable connection.... consistant speeds and no packet loss is much more important than raw speed. Most connections these days are fast enough for wc2, although YES any game where 2 clients are pinging 3500 will have unplayable lag.
(edit)
oh and of course you can ping another player any time you like, as long as you know their IP address. If you are chatting with a friend they can message you their address i.e. 111.222.33.44 and you can just type "ping 111.222.33.44" at a cmd prompt.
.... you can easily find out your external IP address, just google "my ip"
-
When I initially answered I did not realize the server could request player A to send a udp packet to player B and visa versa ..
No, it can't... thats the point. It would have taken 5 minutes and a few lines of code to add when they were working on the wc2 source tho... it would take a lot longer for someone to reverse engineer and patch it in now, but its possible.
-
I realize it cant as of right now.. but didn't realize until yesterday it even has the ability to if given the proper instructions (code)
Interesting stuff though.
-
i got impatient and looked into it myself... i think i was kinda on the right track:
Skype made a technique popular that is called firewall hole punching....
Nice one. Thanks for that, I didn't know that term.
A server with a public address is contacted by the clients. Then it sends an answer back to client A telling it to send udp packages to the router of client B on a port it expect the router of client B to use as source port for the next outbound packet. And it tells client B to send a packet to the router to client A on a port it expects the router of A to use as source port for its next outbound packet. If the prediction is correct, A and B can now talk directly which each other.
.. and yes this is exactly what the server should be doing, but it isn't.... the host client is doing this, but only once the guest clients have successfully connected to the host, which is why the problem manifests at this point.
... the server is doing half if this: its giving the joining client the address of the host client, but it isnt giving the host client the address of the joining client.... which is what the 'solution' I posted suggests.
-
Based on the way it was explained, I would imagine the lat trick would work for multiple people without additional software.. 4 players. A B C D ......./.......Long process, but should work, no?
That's what I think yes. The thing to remember is the only piece of the puzzle missing is the host sending packets out to the joining clients, so if you wanted to do the lat trick with 4 people, and didn't have another game to join, easiest way would be to decide on the host, then have the other 3 people make games. First the host tries to join all 3 games in succession then makes his game, then the other 3 should be able to join that game.
The only thing you are fighting is, whatever internal timeouts the host has for remembering connections. It would depend on your router firmware. I don't know how long this is, but it cant remember the IP address of everything you've ever connected to for ever....
-
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.
Yes, the players would be able to join that game, but the non-host players would 'conflict' with each other
-
One way to fix this *COULD* be to change the route by using a fast proxy or VPN. A VPN establishes a connection over HTTPS between the client and the VPN provider, from where the data would most likely be routed through a different set of servers to the other players.
Interesting if that's posible to make something like NAT substitution for such problem clients. I mean some kind of wrapper between war2 client and network adatper. Say, the problem is between 1.1.1.1 and 2.2.2.2. War2 from 1.1.1.1 sends UDP to 2.2.2.2, that wrapper translates 2.2.2.2 to 3.3.3.3 (another client which connections to 1.1.1.1 and 2.2.2.2 are faster) like kind of vpn. 3.3.3.3 translates traffic back to 1.1.1.1 after receiving answer from 2.2.2.2.
Such kind of distributed UDP antilag-network. With dynamic scanning network performance between each pair of clients and finding the best routes.
Such solutions should be implemented somewhere already. Would be great to get such opensource solution and use for our tasks.
Yes this would be great, but it would not be a small project. Say you built in a layer (storm.dll somewhere, I guess?) that detected packets with an extra custom header designating that they should be redirected elsewhere then had it just strip that header and re-transmit the packet. Then you would have to have each client test its connection to each other client via a third and decide on the best solution. For an 8 player game this means each of the 8 players doing 36 individual load tests. You would have to decide on thresholds for proxying and repeat the test because if everyone decided to use a single client with a nice connection to proxy everything, that client would suddenly have 49x the nework load and its performance would drop..... it's a "movable feast" as my father would say... but it would be very nice once implimented.
Oh, and the gold standard would be this happening dynamically, in game... like when a player has an intermittant problem connecting to some players, it would detect this in real time and start proxying through another client..... Hey, you code it ... I'll cheer you on ;)
--------------------------
In effect it's a kind of VPN ... without the P.
But i think (not sure) VPN's all work through a server, not peer-to-peer, don't they? I'm not aware of any open source project that does this, but would love to hear about it if there is.
---------------
(edit) ..... (again lol)
no, by the looks of it you can configure them to do all sorts of stuff...
check this out (https://openvpn.net/index.php/open-source.html) maybe.
... very late here, I need to get some sleep.
-
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.
Yes, the players would be able to join that game, but the non-host players would 'conflict' with each other
Really? I can't see why. Have you tried this?
-
Appreciate if someone can offer some libraries for keeping UDP interchange between clients or w/e to integrate into C++ project.
I think just standard 'socket' 'connect' and 'sendto' etc. should do it for anything I've been talking about... they're about the only API calls that are identical on Windows and UNIX...
-
One way to fix this *COULD* be to change the route by using a fast proxy or VPN. A VPN establishes a connection over HTTPS between the client and the VPN provider, from where the data would most likely be routed through a different set of servers to the other players.
Interesting if that's posible to make something like NAT substitution for such problem clients. I mean some kind of wrapper between war2 client and network adatper. Say, the problem is between 1.1.1.1 and 2.2.2.2. War2 from 1.1.1.1 sends UDP to 2.2.2.2, that wrapper translates 2.2.2.2 to 3.3.3.3 (another client which connections to 1.1.1.1 and 2.2.2.2 are faster) like kind of vpn. 3.3.3.3 translates traffic back to 1.1.1.1 after receiving answer from 2.2.2.2.
Such kind of distributed UDP antilag-network. With dynamic scanning network performance between each pair of clients and finding the best routes.
Such solutions should be implemented somewhere already. Would be great to get such opensource solution and use for our tasks.
Yes this would be great, but it would not be a small project. Say you built in a layer (storm.dll somewhere, I guess?) that detected packets with an extra custom header designating that they should be redirected elsewhere then had it just strip that header and re-transmit the packet. Then you would have to have each client test its connection to each other client via a third and decide on the best solution. For an 8 player game this means each of the 8 players doing 36 individual load tests. You would have to decide on thresholds for proxying and repeat the test because if everyone decided to use a single client with a nice connection to proxy everything, that client would suddenly have 49x the nework load and its performance would drop..... it's a "movable feast" as my father would say... but it would be very nice once implimented.
Oh, and the gold standard would be this happening dynamically, in game... like when a player has an intermittant problem connecting to some players, it would detect this in real time and start proxying through another client..... Hey, you code it ... I'll cheer you on ;)
--------------------------
In effect it's a kind of VPN ... without the P.
But i think (not sure) VPN's all work through a server, not peer-to-peer, don't they? I'm not aware of any open source project that does this, but would love to hear about it if there is.
---------------
(edit) ..... (again lol)
no, by the looks of it you can configure them to do all sorts of stuff...
check this out (https://openvpn.net/index.php/open-source.html) maybe.
... very late here, I need to get some sleep.
Of course it's not a small project, but i hope to link it from several separate parts. Not unresolvable task for experienced network programmer (in theory, if we find one of them).
Part 1: I'm not about to make some storm.dll research and inject code there. I'm talking about some solution to put in the middle between any application (war2 in our example) and network adatper. I don't know such solutions, but they should be released already. The easiest implementation i see is hooks for several winapi network functions.
So, we can just make some additional traffic between clients or maybe from all clients to a server. Maybe just additional tcp or udp connection to different port. Now, we know all latencies between all clients talked to each other.
Part 2: Another part is additonal headers to UDP packets for rerouting. Quite easy part.
Part 3: Connection management. Receives all the latencies continuously, building and rebuilding it's own map, returns the map for optimal network every moment. Receives all the clients and latencies from part 1 and enforces management using part 2.
Of course very difficult to write this from scratch, but i trust there are some ready solutions to resolve the same problem.
I'd look into distributed networks, p2p networks, VoIP technologies, etc.
VoIP is very active direction for current IT-networking, it uses UDP for it's traffic and it's main task is to make as good connecting as possible. Should have some ready to use solutions.
-
i got impatient and looked into it myself... i think i was kinda on the right track:
Skype made a technique popular that is called firewall hole punching....
Nice one. Thanks for that, I didn't know that term.
Yes, hole punching is the thing known as lat trick in war2. Some other related terms are: STUN or even ICE: combination of methods to maximize the chance for successful connection between all the clients.
Would be great to find ICE implementation for our purposes.
As i see, a C++ class/library to include into war2 loader.
Just thouhgt: would be great to find good network programmer/engineer for war2 project:
We could handle the whole war2 network behavior ourselves: to guarantee all the UDP connections between all the cilents, to manage and find optimal routes for that connections, or even to reroute if clients will suddenly change their IP during the game.
UDP over internet is far from perfect and has lots problems. So, some kind of layer between raw war2 UDP and internet (like distributed UDP network between war2 clients) based on new technologies and implementation is what we need.
-
As i see, a C++ class/library to include into war2 loader.
Just thouhgt: would be great to find good network programmer/engineer for war2 project:
We could handle the whole war2 network behavior ourselves: to guarantee all the UDP connections between all the cilents, to manage and find optimal routes for that connections
Sounds like fun, but as I say, a lot of work. Personally I have far too much to do right now to be able to seriously commit to a project like this, although if you want to do it, I will help where I can. Even just writing these posts is taking more time than I really should be spending on gaming.
There are a lot of things to consider when routing network flow. Here is an example of some of the basic issues: [Network Flow I] (http://www.cs.cmu.edu/~avrim/451f11/lectures/lect1025.pdf) …. after that you can start factoring in some of the more technical bits.
Perhaps there is already an open source solution that would fit what we need for wc2, which could save the need to code the flow analysis/decision making from scratch, but even assuming that is is already done, just hooking this in along with the necessary support code to adapt the client to use it is a big job.
We must also remember that what we are always striving for is reliability and minimum latency, not maximum flow. Every extra step that is placed into the nework logic inheranty adds latency. A small amount of this to side-step disasterous connections between individual clients could add up to a net gain for the reliability of individual games, but too much of it and you're using a flame-thrower to get the weeds out of your lawn… the weeds are gone, but so is the lawn.
reroute if clients will suddenly change their IP during the game.
I think this would be a very rare event.
UDP over internet is far from perfect and has lots problems. So, some kind of layer between raw war2 UDP and internet (like distributed UDP network between war2 clients) based on new technologies and implementation is what we need.
UDP packects are inherantly no less likely to arrive at their destination than any other type. By rights, it *SHOULD* make absolutely no difference. There is a difference, but that is not due to any problem with the UDP spec, it does exactly what it was designed for. An explaination requires a bit of discussion about netowork data streams, so....... Packets are arranged something like this like this:
This is a very simplified version just to illustrate the principles, there are other fields not listed here
Internet Layer: An IP packet:
{version, size, protocol, src address, dst address, {Payload - 'size' bytes of data}}
Transport Layer:
UDP Packet:
{src port, dst port, size, checksum, {Payload - 'size' bytes of data}}
TCP Packet:
{src port, dst port, sequence number, size, checksum, {Payload - 'size' bytes of data}}
So at the internet layer, a UDP packet looks something like this:
{version, size1, 0x11, src address, dst address, {src port, dst port, size2, checksum, {Payload - 'size2' bytes of data}}}
... and a TCP packet would be something like:
{version, size1, 0x06, src address, dst address, {src port, dst port, X , size2, checksum, {Payload - 'size2' bytes of data}}}
So accoring to the original design, the IP packets are only being routed based on the information in the IP header which is pretty much just the address and the number of bytes. Its only when the packet is received by the network drivers at the other end that the IP headers are stripped and the payload is then passed on to the appropriate transport layer driver that the internal headers are inspected.
The IP header does, however contain a protocol (https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers) field, which for these 2 cases will be set to either 0x06 for TCP or 0x11 for UDP, so servers along the way can see what type of data is in the payload and possibly decide to do something different with the packet.
Without an actual decision being made about it somewhere along the way, neither TCP, UDP or any other transport layer protocol is any more likely to be reliable than another. The main difference between TCP and UDP packets is the inclusion of the sequence number in TCP and the behaviour of the drivers handling transaction. TCP simply puts a number on each packet when it is sent, like the page number on a book.
So if the TCP driver receives packets 1,2,3,4,6,7,8 it sends back a request saying "hey I'm missing packet 5 - send that again!", and it blocks forwarding packets 6,7,8… etc. to the application until packet 5 is received and inserted into its correct spot in the data stream. This great for reliable data transfer, but terrible for anything that requires real-time transfer. This is why things like VoIP and live video streaming use UDP, because for them having the latest real-time data is more important than worrying about a tiny fraction of the data that was not received.
BUT…. and this is the big but… what if you are attemting to write firmware for a network router? What do you do when there is congestion in the network and you simply cannot transmit all of the data that you have received? Lets pretend that you are only getting TCP and UDP packets (indeed they make up the majority of the transport layer bandwidth). What if you drop a TCP packet? The driver at the other end is just going to send back a request for the missing packet, then the source is going to re-transmit the packet and you have just doubled your congestion problem.
On the other hand, most of the UDP traffic is stuff like VoIP and you know that a) losing 1 in every N packets in a VoIP stream doesn't stop it from functioning, it just gives a corresponding loss in signal quality and more importantly b) If you drop a UDP packet, most times this will just be accepted by the clients and you won't have to handle the traffic from them requesting and retransmitting the lost packet. Considering this, its no surprise that generally when a server is facing network conjestion issues the first thing they start doing is dropping UDP packets.
O.K. so lets just stamp all our packets with a 0x06 instead of an 0x11 right? So the servers will think the payload is TCP and be less likely to drop it… Nice in theory but there's a couple of issues with this. Firstly, the IP packet header is being written at the driver level, so it's not just a matter of altering wc2 client you would have to be hacking the network services on the machine it's running on (no thanks) and second, stateful and application layer firewalls are quite commonplace these days. These firewalls do inspect the payloads of internet, transport and even application layer packets looking for things like malicious activeX controls and the like. These would instantly flag incorrectly labeled IP packets and a the very least delay them if not block them all together.
ISPs also use a certain degree of this type of packet inspection to manage their bandwidth, for instance on Monday afternoons my torrenting speeds drop to about 10% of what I get the rest of the week. Torrents are distributed via anonymous peer-to-peer connections, and in theory my ISP should have not even know that the packets contain torrent data, but you can be very sure that they do.
These types of issues are why I suggested using a fast VPN *COULD* be a way to improve a bad connection. Inherantly VPNs have a lot more overheads associated with them so should have higher latency that just sending UDP packets, however govornments, corporations and all sorts of high paying customers for the ISPs tend to use VPNs, and being secure, there is no way for anyone to have a look inside and know exactly whats there, as a result many ISPs tend to give high priority to this type of traffic, and they are the last type of packet that is likely to be vonluntarily dropped by a server.
…. and at this point, like so much that happens in our little community, our issues start to become less about network engineering and more about social engineering. ;)
-
As i see, a C++ class/library to include into war2 loader
Have you considered trying a later version of storm.dll?
I know that it was further developed for some years after bne was released, as was PvPGN, so provided that Blizzard kept it backward compatible (I'd hope so, they're generally pretty good) the latest compatible version of storm.dll might possibly be a pre-written 'drop-in' upgrade for the whole networking thing.
IDK what version CE uses already or if Blizzard made any improvements to the underlying networking code that would actually help, but as far as potential "bang for your buck" goes it might be worth checking out.... just a thought :)