Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Lambchops

Pages: 1 2 [3] 4
31
Server.War2.ru / [fixed] Server Hiccup
« on: December 25, 2017, 06:29:13 AM »
Server Problems,

The server has had a bit of a hiccup.

Stats are gone and almost all commands are reporting that they're reserved for admins:
i.e. /whois /finger /games .... even /m

I'm sure you will be able to restore a backup and fix it, just letting you know.

@mousEtopher @iL ... and the rest heh :)

Merry Christmas

32
Boredom Zone / Fractals anyone?
« on: December 12, 2017, 10:20:33 AM »
So i was talking to mac about code to handle complex numbers the other day - which ineviably led me to waste a meap of time messing around with the mandlebrot set.

Been done a million times before, but I can't help myself..... it's just soooo pretty.

 :critter:








33
Moderated General Discussion / Hello, beautiful people.
« on: October 18, 2017, 06:55:33 AM »
If anyone's been wondering, no I'm not dead, but I have been off the air for a few weeks.

Having finally moved into my new pad, I thought I should check in.

Hey   :)

... ok, so in a few days once I'm settled in I should be back to my usual M.O.

did I miss anything epic?

34
Server.War2.ru / [fixed] the SS page is broken
« on: September 06, 2017, 06:50:55 AM »
ss.war2.ru currently returns:

"Fatal error: Call-time pass-by-reference has been removed in /home/sswar2/public_html/index.php on line 115"

35
Flame Wars & Offtopic / these flames are pathetic
« on: July 17, 2017, 11:55:05 AM »
you all suck at flaming.
so do all your mothers.

you all come from suspect ethnic backgrounds and have unsatisfactory genitalia.

lift your game you bunch of newbie scrubs.

 ;D


36
Server.War2.ru / Best forum feature ever...
« on: April 21, 2017, 06:51:28 AM »
:critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter: :critter:

OOHHHH YEAAAHHH BABY!!!!!

       It's a lambicon!      :)

.... or is that an emotilamb?  ;D

     w/e lol.... that is quite seriously the highlight of 2017 for me.


Fully  AWESOME        :critter:  :)


37
Server.War2.ru / Full Map SS Grabber
« on: March 06, 2017, 02:32:03 AM »
Instant SS of entire map.

Get it HERE



updated icon <3 mousey

38
Mods & Development / The server status web page
« on: February 19, 2017, 08:53:49 PM »
The server status web page is very cool. Its my homepage - i should take it off there because it always distracts me when I see a game on and I end up playing wc2 all day lol...

Have noticed one small inaccuracy with it though; The in game time displayed for a game's host seems to show the time since they joined the channel afther their last game, not the time since they made the game. i.e. 4 people finish a game - then chat in the channel for 10 minutes then someone makes a game and all join it will say something like: Host 10 minutes - everyone else 30 seconds.

Not a big deal if there is some reason why it's like this, and its a pain to change - don't worry about it. Just thought the author might want to know, in case they didn't notice ( I didn't notice fore ages...)

39
Website & Forum Discussion / The old forum has gone?!
« on: December 30, 2016, 05:19:00 AM »
I guess it had to happen eventually, but it looks like the old forum at http://war2.warcraft.org/forum/ has finally gone :( or at least its down right now.

But it doesn't look like it's just down because the homepage of warcraft.org is still there collecting clicks, but all the links on it are broken. Maybe (hopefully) I'm wrong.

Anybody know if there's a backup/archive of this anywhere? Would be a shame to lose all that history (lame-ass flame wars and all)


40
Server.War2.ru / WTH is a lag hack?
« on: December 23, 2016, 01:25:57 PM »
So I thought I'd have a couple of games, and this LeeRoyJenkins guy was hosting. So I pwnd his noobish ass twice, and the second time he just starts going off his nana at me and bans me from games.....

OK fine, I know some of them have little emotional issues when they lose, it's annoying but I'm sure they can't help it - nobody would draw that much attention to how bad they suck if they could avoid it.... but here's my question:

WTH is a lag hack?

im pretty sure thats what he said

like "nice lag hack" "hacker trash".... blah blah blah ( I have no skills and want to cry about it )

The thing is the game wasn't lagging, i mean at all. It was set on low lat and still nice and smooth?

Normally if someone was being a dick like that I'd just go get a smurf name and not worry anout it, but I'm just kind of fascinated....

I mean I'd guess at a "lag hack" being something that creates lag (aka gay porn) but there wasn't any, so is this toolbag actually on about anything or did he just say the first stupid shit that popped into his tiny mind?



41
Mods & Development / A collaborative PUD editor.
« on: December 20, 2016, 01:26:54 AM »
Following the discussion on THIS thread, I thought a collaborative project to make a PUD editor might be a good first step to get all the geeks with ideas working together.

This would be made using ASM, and with as many people as are interested contributing, and the source code being publicly available to all.

I want to use ASM as any real game modding beyond the basic substitution of constant values in the exe requires an understanding of machine code, and a simple project such as this would be an ideal way to create a common platform/language that we can collaborate with.

ASM is actually pretty easy to use. Once you get your head around it there is actually a lot less syntax and fewer rules to learn than higher level languages i.e. C++, java etc.

Ideally people who have some programming experience would be helpful, but it is not necessary to know ASM. I can get it started and show you how to impliment things that you are familiar with from other languages.

Project components:

  - Define/develop an internal container for PUD files.
  - Load/Save PUD files to/from this container.
  - GUI to display the PUD, Select objects/regions etc.
  - Individual editing modules to perform editing tasks
     i.e.
          - Unit properties editor
          - Map properties editor
          - add/remove units
          - ???specialised tasks???

  - Other utility modules to perform non-editing tasks
     i.e.
          - Make a BMP from a pud
          - Dump PUD statistics to a file
          - ???Whatever else anyone can come up with???.

I have a few ideas, and I know there's at least a few others out there who have good ideas/skills. This is an easy way for people to learn to program in assembly, and as the PUD format is well known and documented nobody has to worry about others taking advantage of their research, or using it to develop hacks.

By the time we have done this, we should have the common ground and communication we will need if we are ever going to have a go at collaborating for some genuine WC2 modding/improvement.

Anybody who wants to be involved, please reply to this thread.
Please leave a rough description of where you're up to:
i.e.
        "I am helpful, learn fast, and have lots of enthusiasm"
        "I have some programming experience"
        "I'm quite experienced in programming but not so much in ASM"
        "I'm a freakin guru"

Unless you are best described by one of these two:

        "I could help, but I have more fun trolling"
        "I just like trying to sound important, but dont actually contribute anything"

In which case just go join one of Dellam's chop games and let the adults talk.  ;)

42
Website & Forum Discussion / please explain to polandd
« on: December 07, 2016, 09:29:47 AM »
Please explain to polandd that he must post a SS when asked.

If he does not post, I think a 1 week suspension is appropriate. Mostly because he's a new player that needs to be discouraged from MHing, but also because he has just learned how to rush grunts then turned into an abuse spewing asshole.

Also would someone please tlee Yamon that sitting in the channel telling people NOT to post SS when asked is not appropriate. As a long term player Yamon should be educating and encouraging new players. But instead its example #473 of Yamon being a dick.





43
Mods & Development / mine distance for claw
« on: November 09, 2016, 05:31:06 PM »

ok first thing I have to say is:

You are absolutely right, kurwa. They are not the same distance, but I still have an explaination for you.

I was concentrating on making sure the distance was 4 between the halls (same as hall width), but of course the minimum distance between mine and hall is 3 not 4.

My bad... not enough sleep...

But I can still explain why. Will post that soon, but wanted to say that as its been more than the 10 minutes i promised.

44
Mods & Development / Nerd's Corner
« on: October 31, 2016, 08:27:45 PM »
I found a bit of writing I did about NAT a while back. There's been some talk about this recently, so I modded it a little bit to make it more relevant to WC2, as I thought the more nerdy folks out there might find it helpful.

So NAT. What's it all about?

Lamby's super-abridged, mostly fictional, oversimplified, heavily biased synopsis: Network Address Translation is a messy, stop-gap measure that got dreamed up by psychotic, sadistic and under-medicated network engineer as a way to get more flexibility out of the already overcrowded IPV4 address space prior to the implementation of IPV6.

Most people know by now that IPV4 – that’s the 4 numbers with the dots in-between that we all recognise as an IP address - was just too small. There just wasn't enough numbers. Its a 32 bit value. 2^32 = just under 4.3 billion possible addresses. Seemed like a big number 50 years ago, but even 20 years ago people were realising there weren't enough to go around.

IPV6 has now been implemented, which has lots of address space - like crazy lots =). We still see IPV4 addresses on the surface, but the backbone of the internet is now all IPV6, and all those things like credit-card gobbling parking meters that all need their own address just have IPV6 addresses. IPV4 is still around to interface with all the existing technology.

So IPV4 addresses were just not cutting it – it's 4 measly bytes, and that limit was (and for the most part still is) hard coded into every bit of network infrastructure in the world. But! Thought the madman, most of the traffic is TCP and UDP, and they have this port number. It's another 2 bytes! What can we do with that? NOTHING you maniac, it already has an important function, leave it alone. But no…. We get Network Address Translation, and we'll probably be stuck with it until the end of days. Post nuclear holocaust the only things to survive will be cockroaches and NAT.

So yes, a port number is 16 bits (0 thru 65535) and only a fraction of them are actually used. Officially ports 0-1023 are 'system ports' and stuff above that can be registered by people who want to put their official stamp on them….. or you can just pick one that's not getting used too much ;) Wikipedia lists around 1300, including 3 entries for port 6112:

Code: [Select]
6112 TCP UDP dtspcd, execute commands and launch applications remotely,  Official
6112 TCP     Blizzard's Battle.net gaming service and some games, ArenaNet gaming service, Relic gaming service,  Unofficial
6112 TCP     Club Penguin Disney online game for kids,  Unofficial


Anyone spot the mistake? … battle.net port 6112 listed as TCP only. (nvm, I already fixed it – the guy maintaining the page sent me a rather curt little message about 'original research', but he left it because he knew I was right;)

So how many possible port numbers do we need? Well I think we can safely say its more than 256 (1 byte) and less than (256x256) 2 bytes, so allowing 2 bytes is about right. But how many port numbers are actually used every day? Depends who you ask… let's see well 53 is DNS, that’s a cert, and 80:HTTP, more to the point these days 443:HTTPS, 20-21:FTP maybe not daily, 37:TIME gets used behind the scenes, 25:SMTP (email) used lots, but not so much from home any more, these days its all secure web pages (443) and poor old 110:POP3 is well on the way out. I could go on,  hey I love that Doom still officially owns port 666, (a system port 8P) but in reality most of the traffic in an average network on an average day probably uses maybe 50 ports? Who knows, maybe 100? Ok so lets say, for the sake of argument, its 100…. but we have 65535 possible port numbers, so lets go ahead and divide that by 100 and now we can support a network of 655 individual nodes off a single IPV4 address.

How do we do this? Well we just have to introduce an agent at the crossover point between our NAT network and the real world.

The following description is, of course, complete and total rubbish for so many reasons… there are different types of NAT and different ways to implement things within them, and I'm no expert. This is just here to hopefully help people who know nothing at all about the subject to get their head around the general concept.

Think of it like a (crazy) guy with a clipboard who writes really fast and looks at every packet that goes past. First he sees an outbound packet from puter 20 on port 3000, he says “call it 10” and writes down 10 = 20:3000, then he changes the source port number to 10 and sends the packet on its way. Next there's an outbound packet from puter 44 on port 8008, so he writes down '11= 44:8008', changes the source port number to 11 and sends it on its way. Next there's a packet from puter 150 on port 3000…. '12 = 150:3000' …. off you go… he does this a lot.

The packets, with their re-assigned port numbers go to wherever they were going and (as is the nature of things) they get responses from remote computers somewhere in the world. Those computers do whatever they do with the payload – the chunk of data that this addressing system is carrying – then they send back their response. There's to and from IP addresses and a source port and a destination port. The remote computers received the packet on the destination port, and you guessed it, for the return journey its all switched around: the to address becomes the from address and vice-versa, and the source port becomes the destination port etc., and the return packets get sent back to the addresses that the initial packets were received from.

The thing is here, that as far as the remote computers are concerned, these packets all came from the same computer, because they were all using the same external IP address as the from address, so they all arrive back at the same place and are greeted by the loony with the clipboard who looks at the packets, then checks his clipboard and says “hmm, port 10… that's puter 20, port 3000”, so he changes the destination port to 3000 and the to address to puter 10's local IP address and sends it on its way.. etc. When he gets the port 12 return he sends that to puter 150, port 3000.

So 2 different computers on the local network have simultaneously requested data over port 3000 from 2 separate remote servers using the same external IP address and both receive their replies, on the same port, and are none the wiser that for most of the journey their packets actually had completely different addresses and ports on them. Likewise the remote server has no idea that the originating computer is not receiving the packets on port 10 or 12, but on port 3000. But because of the way NAT works it never matters because the nutter in the middle keeps untangling his own knots on the way back.

Why do it this way? When you think about the amount of data that is sent around just for one Game of Thrones episode, its colossal compared with this tiny little 2-byte port number… so why mess with it? There is, of course, a very good reason. It's because every piece of data in every layer of every packet is ordered according to some protocol or other, and somewhere along the line, some computer is going to process that data. So if you add data, or introduce some new protocol, it means the computer at the other end has to understand that change and correctly process it, or even just know to ignore it (Unless you're meta-tagging an mp3, which is just deliciously naughty – but that's another story;). NAT works by sneakily messing with the existing data so that the remote computers just process it in according to their existing protocols without having to be aware that any translation is taking place. In this way it can be introduced in a single location, to suit local purposes without having to upgrade the entire internet (which wasn't in the budget that quarter).

Well. That sound's really clever… so what's wrong with that? Well…. nothing …. and everything. Hmm, how to explain…

You know when you have to move house? You pack everything into boxes and it gets loaded onto a moving van, then unloaded at the other end and you try to reconstruct your home. To make this a bit easier, you no doubt write “kitchen” or “garage” on the boxes, maybe even “kitchen – glassware” and “kitchen – plastics”. This way you have an idea about where everything goes when you get to your new home. Also the guys from the moving company might even notice that a box says “glassware” and decide not drop it 8 feet off the back of the van onto the road with the rest of them (maybe?). Good idea.

  - - >  So your address is where your new house is, and the extra note about what the box is being used to move, and exactly where in the new house it needs to go when it arrives, can be thought of as the port number. < - -

So now what if 500 people are all moving interstate on the same day, and they are all using the same moving company? Bit of a worry.. ok then, let's up the ante a bit more... What if there was a little snafu and instead of printing address labels for 500 different addresses somebody printed 10,000 labels all with the same address on it and for whatever reason they had to use those labels, and the only place to write any notes on the boxes is in the one little space provided on the address label and that note space just is not big enough to write the correct address? How can this work? Well, says the madman with the clipboard. It seems everyone is writing “kitchen” on these things, hey I've got an idea! There's lots more words than just that…

How about if I write “unicycle” on this, that means “bathroom at the Jones house”, but if I label it “golf balls”, that means “kitchen at the Smith house”, and if I put down “proverb” that means garage at the Bloggs house. Then I can just keep a list here on my clipboard, and when when we get to the next state we can just look at the list and send everything where it needs to go.

As insanity would have it, it turns out this guy really is obsessive-compulsive enough to do this and he correctly decodes the labels on 10,000 boxes and sends them to the right house. He even crosses out “golf balls” and re-writes “kitchen” so Mrs. Smith knows where to take her (broken) glassware. Pretty neat trick right? Perhaps, at least until you have to cross some border where there's a security check, and the customs agent decides to check out your unicycle and discovers instead, bottles of shampoo and other liquid product, which we all know is what terrorists use to blow up planes so… oh dear… Mr. Customs agent rather ominously snaps on a rubber glove and asks you to step into a small cubicle…. and Mrs. Jones never does get her hand sanitizer back.

There are some important protocols that include some form of auditing of their own packets, the most obvious being IPsec or “Internet Protocol Security”. IPsec encrypts packets at the internet layer, which of course includes the port data which exists at the transport layer, so if NAT changes what it assumes is the source port number the packet has been corrupted and can't be decrypted.

The real problem is that the crazy-guy is messing with the language that everybody speaks. Nowhere in the universe, apart from in his twisted head, does “unicycle” mean “shampoo”. Its all well and good for stuff that he handles first, but when Mrs. Jones' mother tries to send them a pot-plant as a house-warming gift, the crazy guy re-labels it 'special fried rice' and sends it to Alaska.

And this is the problem with NAT for WC2. Battle.net is NOT a gaming server for WC2 games, its more like Craiglist. It just advertises the games. Initially the host's computer is the server, then it's mostly just peer-to-peer. The 'server' (BNet, PvPGN etc.) just relays messages and keeps track of the stats when the game ends. But, the other clients aren't replying to packets that the fruit-bat has already messed with, they are using the actual correct information that was posted in the game list, or supplied by the game host. So when a packet arrives at the NAT agent labeled “WC2 Game”, our friend looks at his clipboard and says, “oh, you're a medium sized flock of migrating geese” and points it towards the equator.



NAT is an IPV4 thing only. There is no IPV6 Network address translation, its just not needed, and here's why:


The IPV6 address space contains approximately:       
340,282,366,920,938,463,463,374,607,430,000,000,000 addresses.

The zeros on the end round it off to the nearest 10 billion addresses.
The entire IPV4 address space is under 4.3 billion addresses.

Assigning a trillion trillion IPV6 addresses to every person on the planet would account for less than 0.01% of the address space. Pretty sure nobody wanted to have to upgrade the internet again.

An IPV6 address uses the same amount of bandwidth as writing BOOBIES!
…… Damn I love numbers (and boobies :P)


45
Server.War2.ru / Server Lag : what it is and isn't....
« 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: User Datagram Protocol
                  and
   TCP: Transmission Control Protocol


The difference is this:
- TCP makes a connection between 2 computers, in this case a player's computer and the server. Once a TCP connection has been made, the TCP 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 does not do this at all. If one computer sends a UDP 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 protocol (whereas it is built into TCP).

There's also another 2 terms I'm going to use a bit which are:


   IPX: Internetwork Packet Exchange
               and
   IP: Internet Protocol


- IPX is just an old network protocol that is no longer used. Although internally different, as far as the descriptions above go, IPX can be considered the same as UDP. 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 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 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, however here I'm talking about the protocol itself. When I'm talking about an IP address I say "address".


So... going back to 1996 and 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. For those of you old enough to remember Kali this is where that fits in. Kali is an IPX emulator, so it allowed people to play multiplayer games based on the old IPX 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 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 connection. This connection is established when you logon to battle.net and (being TCP) 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 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 connection and give it a list of games. This list includes the game name, the pud, the settings, and most importantly the 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 (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 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 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 connection is established with the server, the underlying IP "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 connection to the server, which gives you the IP address of the host. So your client sends a UDP 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 packet turns up from some random client, the IP 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 running in your hardware to associate traffic over that port with a certain IP address.

But if you can't get UDP 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 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 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 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 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 packets at everyone else.... and 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.

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 connection timing out. As we know TCP connections are "guaranteed" by the TCP 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 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 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 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 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 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 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 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 traffic. As pinging is a "control message", operating on the ICMP protocol - which is usually prioritised by servers, if the connection is being throttled at the TCP layer, it could leave other IP 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 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.


Pages: 1 2 [3] 4