War2.ru Slogan
News: All hail our wise & benevolent admins!

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.War2.ru board & let us know who you are on the server.
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.

Messages - Lambchops

Pages: 1 ... 105 106 [107] 108 109 ... 111
1591) Mods & Development / Re: Server Update
« on: November 02, 2016, 04:21:03 PM »
The most I've gotten to is war2 sitting at black screen when I used my maps bigger then 128x128. I think I nulled out the minimap and it no longer crashed. But I was stuck there and clueless. What do you think about that?

I think you gave up to soon ;)

1592) Mods & Development / Client Update!
« on: November 02, 2016, 09:50:22 AM »
there is one WC2 mod that is head and shoulders above everything else absolutely screaming out to be implimented.

That mod is breaking the 128x128 map size limit. Historically I know this has been looked at before, but I dont see why it couldn't be done.

It also leads to another 2 mods that I would like to see, and they are :
 - Increasing the game display from the rather miserly 14x14 window we currently have
 - Breaking the maximum per game unit cap - cannot create unit - this one could possibly be quite easy.

Internally locations are mostly stored as 2 WORD size variables and often passed or referenced as a single DWORD argument so most of the game code already supports a map size of up to 65536x65536. There are, however parts of the code that impliment WORD sized absolute pixel co-ordinates, which restricts things to 2048x2048, but even this would be pretty cool.

Implimentation would not be trivial, but it could be almost all done just by modifying the existing code without actually having to add any new code in.

We would have to do this (at least!)

- Mod existing PUD editors to allow the creation of large maps.

- redefine the valid .PUD check so the clients will accept larger maps

- Mod things like any internal co-ordinate checks that may declare co-ords >127 to be invalid, it would be nice if these would all be based on the map size in the PUD file, but as there are currnetly only 4 legal map sizes there will probably be sections that are hard coded to make calculations based on one of these 4 sizes. All this code would ned to be chased down and modded or re-written.

- Increase any buffer allocations to allow for bigger maps, possibly parts of the executable's .data and .data? sections will also have to be redefined to allow more space.

- Check and mod the display code to allow for larger maps. Scaling for the mini-map is an obvious one, as is the buffer that keeps the background updated (this one is why you can see where trees are chopped even if you don't currently have vision there).

The main view code probably wouldn't have to be changed at all apart from any checks that just flat-out reject large co-ords.

.... Possibly by this time we might know enough about the display code to increase the 14x14 window size by having the internal routines draw the units to a larger buffer, then resizing that image and pasting it onto the existing screen buffer. There are also a bag of issues related to translating mouse input from this resized window.

--> This also leads to running the game at higher screen resolutions, which would be nice, but that would be another BIG mod. Where do you draw the line? It would be nice for it to actually be done before we are all too senile to enjoy it ;)

Breaking the unit cap should just be a matter of increasing the buffer allocation and finding any bits of code that impliment:

if n_units>MAX_UNITS {say "BLEH!"}

1593) Mods & Development / Re: Server Update
« on: November 02, 2016, 08:47:49 AM »
Quote from: CLAW on October 31, 2016, 02:37:25 PM

    couldn't this be archieved by save game?

    We should direct our developer's attention (if we have any) on things that would largely impact our quality of life while being not so hard to implement (hardware ban hi)

Well, some kind of autosave could be a key. Also, autosavr could be a separate project not related to others (like hardware ban), so it can be implemented by somebody who wants (and can) to help.
Another question is if that is really useful: even if we have saved game, we have to join all the previous players together again. Not so easy task to make them do that.

Quote from: Lambchops on November 01, 2016, 06:26:52 AM

    Then you would modify saved game state to show that the disconnected  player is still in the game, then restart the game from the modded save. If you could automate the process it would in effect allow players to join a game in progress, but it could make the game suceptable to all sorts of exploits.

I'd say just to make saves periodically, considering disconnects. To let hoster know which save-file should be reopened. Game load could be a manual process.

To be honest, I've never used the save game feature for a multiplayer game, but modding/automating features that already exist in the game is much easier that trying to introduce entirely new ones.

I've always assumed the save game feature makes a file based on the existing game state with info about the players and the current state/actions of each unit - then you just start a new game based on a combination of that file and the original PUD.

Just did a few tests on my own and it seems pretty good at restoring the game state. i.e. spell effects/corpses/current actions etc. were all resumed.

With several players in the game i assume it only lets the same players join the restored game? I know the dialog says that only the host can save the game so I assume it is only saved to their computer, so when it is restarted the save game file has to be downloaded by the rest of the clients?

I don't imagine autosaving would be terribly difficult. Certainly it would be trivial with a macro, but that would be intrusive to an active player. Periodically calling the save game proc with an auto-generated file name (autosaveXXX.mlt) shouldn't be too hard though.


*In theory* allowing a player to join a game in progress could be achieved by something like this:

Trigger the clients with a pre-defined in game messages... with some sort checksum based on the stuff about the current game.

So the player wanting to join messages a player in the game /m player #join

The clients have a bit of code injected into them so if they detect incoming messages with a '#' prefix so if they get a "#join" message incoming they generate an in-game message that all clients see like "#request:JoiningPlayer:945B98D1"

The #request message triggers the host to message the joining player details game datails like "#invite:"

The joining client then replys with "#confirm:join:945B98D1"

When the host gets time they generate an in-game message like "#restart:"

The rest of the in-game clients reply with "#confirm:restart:945B98D1"

When all clients have confirmed, the host save the game then sends "#execute:945B98D1" both to the joining player and in game.

All clients then leave the game.

The host client mods the save game file to include the new player, and creates a new game from the save, while the non-host clients join the created game, along with the joining player.

The host would wait for all players to join the new game then start it and the game would continue.

Ideally the new game would be created and players would join without using the server game list mechanism, the server would only be used to relay message to/from the joining player.


This is, however, a lot of work for what is debatably little benefit.

What is the use of it? For a player to rejoin if they lag out? If they are lagging they will probably still lag when they rejoin, and if everyone agrees this can already happen with the existing game save if they do it before the player actually drops.

If the joining player wasn't already in the game what do they start with and where? 1 peon at an unused starting location? What if an enemy already has an exp there? How are they going to catch up anyway? Really, what's the point?

I suppose it might be nice for people to be able to join as watchers, but is that really worth it? What if a lagging watcher joins a game? What if people keep joining and leaving causing annoying pauses in the game?

The .MLT files are much bigger than .PUD files, and the game's download procedure is VERY slow... The biggest .PUD files are around 120KB. Using normal network protocols, this should take less than 1 second to download even on a slow connection, but as we all know whatever method the game client uses is MUCH slower than this. My test .MLT file it 530KB so it would seem using only existing features a game restart is going to take maybe 2-5 minutes (yuk).

The other thing about this mechanism is is that there is a massive security issue, in that while the game is being restarted, a single client has the one official version of the game state, so at that moment they can play God and change anything at all in the game.

This potential exploit, however has some interesting possibilities for creating RPG style campaigns and the like... i.e. when set of triggers in the game is satisfied, the game can be automatically restarted with any changes the designer wanted... introducing new cpu enemies, allowing certian units/abilities that were previously restricted. It's a nice concept, but for the probably thousands of hours it would take to impliment, at that point you may as well go play wc3.


For my money, there is one WC2 mod that is head and shoulders above everything else absolutely screaming out to be implimented. (see next post :) )

1594) Mods & Development / Re: Server Update
« on: November 02, 2016, 05:24:08 AM »
Static IP. wireless net gear router. IPv4 address stays the same

I meant the external external address your ISP is assigning to you, that is what the other clients have.

Are you talking about reconnecting to your router or reconnecting to your ISP? Once the game is started changing your LAN address probably wouldn't be a problem, but changing the public address that your ISP is assigning to you would be.

If you were just talking about reconnecting to your router then probably its not your ISP, its a settings/firmware issue with your router.

1595) Mods & Development / Re: Server Update
« on: November 01, 2016, 02:24:46 PM »
I'm not sure if it works on all routers, it's probably isp related. . But when I lived in an apartment I used to get disconnected, drop screen would pop up.. then go for like 10 seconds, then disappear,  then pop back up for another 10 seconds until I eventually dropped.. I figured out I was able to tab out of war2, disconnect from my Internet connection, then auto reconnect and tab back into the game and keep playing without dropping

Yeah that sounds like a busy ISP downgrading the priority of your connection, but when you reconnect you're back at the top if the list. It's pretty common practice. I'd assume they must have been assigning you a static address for you to be able to continue in the same game?

1596) Mods & Development / Re: Server Update
« on: November 01, 2016, 06:26:52 AM »
couldn't this be archieved by save game?

If someone wanted to do it, then yes, the save game mechanism is exactly what is needed. In effect you would be ending the game and saving it - which is then the 'official' version of the game state. Then you would modify saved game state to show that the disconnected  player is still in the game, then restart the game from the modded save. If you could automate the process it would in effect allow players to join a game in progress, but it could make the game suceptable to all sorts of exploits.

1597) Mods & Development / Re: Server Update
« on: November 01, 2016, 06:09:42 AM »
To reconnect to a game if you were disconnected?

This is a 100% client issue and not to do with the server. In fact THIS ALREADY HAPPENS.

This is what is happening when someone lags and nearly drops, but then their connection recovers. While everyone is looking at the lag screen, they are disconnected. Then they rejoin the game.

You really want laggers to be able to rj when they finally drop?

The issue is (again) that a wc2 game is not happening on a server, it's peer-to-peer. There is no 'official' version of the game state, instead all clients must agree to what is happening in the game for it to continue, if one client is out of sync they will drop.

To join a game in progress a client would have to negotiate with all the active clients in the game and come up with an agreed version of the game state, then they would all have to accept the joining client. At that point all sorts of exploits could come up, like people drop-hacking one player to replace them with somebody else who is spoofing them etc.

In the end, if the rest of the clients have decided to boot you, its for a reason - in most cases its either because your connection is too poor to allow the game to continue with you in it, or because your version of the game state is different to everyone else's.

1598) Server.War2.ru / Re: Unban Sepi
« on: November 01, 2016, 05:43:07 AM »
But I must say Swift that I am starting to see that you are not malevolent in nature. I see you make contradictions like this a lot and my first impression was that you were attempting to manipulate. But having watched these patterns long enough I've noticed they are caused by something else (which I do not want to say unless instigated).

I noticed his companys facebook page had a 5 star review done by Swifts friend (I have evidence to prove its a friend). I hate this kind of branding. So I gave the facebook page 1 star to counterbalance the 5 star review.

I don't know Sepi, and I'm not really familiar enough with the whole story to make a call as to who should or shouldn't be banned, but one thing seems very obvious:

At this point Sepi, you have started manipulating someone's real life business based on crap from an online computer game, allbeit in a very minor way. I don't know if Swift has children or other relatives that he supports with this business, or if it has employees who's livelihood depends on it, but I an quite sure that none of these people deserve to have their lives messed with based on whatever crap got up in your head about playing GOW.

Because that is what prompted your actions. I'm pretty sure you didn't go around to the rest of the literally millions of pages that have positive reviews from associates and try to 'counterbalance' them all, did you? You were responding in RL to what happened in a game. That is the line. You crossed it.

That being said, most people have probably done stupid things online that they later regret, I know I have. So just grow some balls and admit you messed up, then everyone can just build a bridge and get over it.

B) why are you not thankful at me for nullifying unjustified review of your friend?

This kind of attitude really does not help your case.

1599) 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)

1600) Server.War2.ru / Re: Port Forwarding In DD-WRT?
« on: October 31, 2016, 06:07:44 PM »
you, sir, are an actual gentleman. thank you very much bro. not actually putting in a range might do the trick, will get stuck into this when i sober up in the mornin. thanks again

YW, glad I could help  :)

Yeah, there's no reason to forward anything apart from UDP on your game port. In most cases forwarding others probably won't hurt, but its unnecessary and could possibly confuse things a bit, especially if you're trying to run more than one client from the same LAN.

Remember you can already join/chat/message etc. without forwarding anything at all. The only thing that isn't getting through is the initial "hi, can I join your game?" message from other players.

When you host, part of the info in the game list is your game port, so people trying to join send UDP packets over that port to your public IP address. The whole deal with port forwarding to host WC2 games is just telling your router to send you those packets.

             UDP:YourPort   -->   your computer's LAN address

1601) Server.War2.ru / Re: Port Forwarding In DD-WRT?
« on: October 28, 2016, 11:49:49 PM »
OK so I fired up the router (it's a NETGEAR WNDR4500) and discovered I had reflashed the stock firmware before mothballing it, so I put DD-WRT back on it, probably better to start from a clean install anyway. Its build 26138 – about 18 months old.

After the standard setup stuff – gateway address, DHCP, DNS etc. I just plugged in the port (6112) and the local IP of my gaming machine (for the purposes of this exercise I called it and I was able to host without issue. But... I'm not using a VPN so that may be a causing problems.

OK So…. Port forwarding:

It's in the NAT section. This is not actually network address translation, but from a coding perspective its right there in the part thats deciding where to send packets based on transport layer info (which is a big part of what NAT does), so it makes sense that it would be grouped there on the config page. The important thing is that 'port from' and 'port to' are both the same so nothing is being translated, its just sending everything stamped with a '6112' to LAN address In fact this should safeguard the passage of port 6112 traffic through any NAT that the router is a party to, although it won't help you if somebody upstream is switching ports on you.

Some protocols can safely pass through NAT, or actually they would be totally destroyed by NAT so they are given a pass. Things like IPsec, so if you have an option to use one of these, it might help.

1602) Server.War2.ru / Re: Port Forwarding In DD-WRT?
« on: October 27, 2016, 03:38:00 PM »
I was running DD-WRT on one of my other routers a year or so ago. From memory it took a while to find the right config page to get it set up to host. Having access to such comprehensive configuration means page after page of settings. Can't remember off the top of my head exacly where it was, but I remember it being about 3 pages deep under what seemed like an unlikely heading. If you're still having trouble I'll plug in my DD-WRT router over the weekend and tell you what worked for me.

1603) Server.War2.ru / Re: Server Lag : what it is and isn't....
« on: October 20, 2016, 05:11:17 AM »
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 :)

1604) Server.War2.ru / Re: Server Lag : what it is and isn't....
« on: October 20, 2016, 04:55:02 AM »
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] …. 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:
Code: [Select]
An IP packet:

{version, size, protocol, src address, dst address, {Payload - 'size' bytes of data}}

Transport Layer:
Code: [Select]

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:

Code: [Select]

{version, size1, 0x11, src address, dst address, {src port, dst port, size2, checksum, {Payload - 'size2' bytes of data}}}

Here size1 is the size of the entire UDP packet, which is the payload for the IP packet, and size2 is the size of the data which is the payload for the UDP packet.

... and a TCP packet would be something like:
Code: [Select]

{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 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. ;)

1605) Server.War2.ru / Re: Server Lag : what it is and isn't....
« on: October 19, 2016, 02:18:02 PM »
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...

Pages: 1 ... 105 106 [107] 108 109 ... 111