Netcode - a serious suggestion

[WarWolf 0]

I really hope that this post doesn't come too late in OFP2 development-cycle to be useful....

If I want to play with some other folks in Australia and USA and Europe (from UK) at the same time, should it not be possible and more importantly - useable and playable for all concerned?  I think an improvement in this situation is long overdue, and I think it wouldn't be as complicated as it first sounds.

Have seen many suggestions about using clustering, dunno if it's going to happen or not, but why not take the concept just one stage further, with improved player-numbers, massively reduced lag, and a better MP experience for all.

Interested?  Read on...

The idea is a simple one, and I don't believe it'd be overly hard to implement, if thought through properly and with due consideration to the (useful and good) abilities of the many server admins out there.

Decentralisation is what I am talking about.  Using the machines connected (and connecting) to a game more wisely.

At the moment I see online games using a central server, with that server's CPU/Conn stretched to the limits, often with a very poor ping or connection at the players end, with predictable desync'ed and laggy results.

So: Why only use one server?

hmm.  Well, co-ordination of the gameplay and synchronisation is obviously required and that does need to be centralised, BUT it IS possible to do that in more than one stage and improve the pings to players simultaneously.

I think an example would serve better at this point...

Fred and Bill want to play on a server together.

Fred lives in London, and Bill lives in Los Angeles.

Currently the best choice for them would be to select a server somewhere on the East coast, probably New York that has the best ping to both of them.  That still means that their game will have the lag of their combined pings, but at least the lag is balanced and desync shouldn't be too much of an issue.  Note that their pings to the server are based on their ordinary household connections.

Now, consider that many servers out there reside on serious sized pipelines, not just the little ADSL connections that we mere mortals have at home, with limited upload speeds etc...

Would it not make a lot more sense for Fred to connect to a server nearby in London, with a tiny ping, and for Bill to connect to a server in LA, also with a tiny ping, and then for the huge bandwidth of those two servers to act as a motorway/freeway/autobahn*  between them?  Even if there still needs to be a centralised decision-server for multiplayer co-ordination, the simple ability to offload and speed up the comms would improve lag problems.

So now think about the inter-player co-ordination.  Say Jill (in UK) joins the London OFP dedi-server and then joins the game that Fred and Bill are playing.... If the London server can handle the synchronisation between her and Fred, whilst still leaving the LA server as 'master' server, then that's less work for the LA master server, AND less desync problems 'cos Fred doesn't sync to Jill via two transatlantic hops.

Now think about that scenario, using 3 or 4 servers co-operating, with 30 or 40 players on different continents, each local server synchronises the players local to itself, then synchronises the result with the other dedi-servers through fat pipelines, which in turn sync to themselves and update their local players.  Game logic etc. COULD be shared by the co-operating servers, however a central server for this processing would also suffice, less synchronising to worry about that way for the time being.

Co-Operative server architecture...hmm even got a name for it.

!!Ok, that architecture could also be a great help when downloading maps to players - sync the maps on the servers first, then download locally from each server - less download time = game starts quicker.....

As an also to the above, would be interesting to see that file-download 'bonus' applied to dedicated addon-servers....useful also for x-box too I'd reckon.

The above blahblahblahetc. could be applied to non-dedi server games also - but some automatic configuration would need to take place to determine the power/bandwidth of connected machines to decide which act as servers - this becomes a knotty problem when disconnections etc occur - and JIG happens - (JIG is an automatic spinoff of this architecture anyway).  I think that for the time being it would be far simpler to make this an additional capability of dedicated servers, configurable by server admins themselves to decide (in which games to which other servers) which server becomes the master...  maybe ping could be used instead, but this isn't a failsafe method so manual tweaking would be desirable.

That is the only difficult part of the design - deciding upon which server becomes the 'master' server.  Perhaps allowing the tailoring of the cooperation between the servers to have multiple setups saved for different configurations.  Like for a game using EastCoast/WestCoast servers have one setup defined, or between continents you'd have a different server defined as master, etc, etc.

What I describe is possible with not too much effort, time allowing of course.  Be cool if it could happen for OFP2...

WarWolf.

p.s. (hint, hint, lol) IF this proves useful, (for OFP2?), you could repay my kindness by giving us an optional more-realistic flight model+non-auto-centering HAT switch view for helicopters - please, please, please (BEG!)  Fly ApacheVsHavoc or ComancheVsHokum to see what I mean by flight model... rudder-pedal / multi-joystick support would also be a boon.....

PLEASE!

[benu 1]

This is only useful if bis would supply all the servers. Other admins pay money for their servers and the traffic and would not want to route the traffic for other servers through theirs.

Eg we pay for our server, we all have a good ping their anyway and would not profit from your idea. Quite the opposite, if we would take part in this we would route and pay for the traffic of people playing somewhere else.

I can only see this modell make sense in an environment where bis supplies all the servers, something like battlenet, not for privately run servers. Those could do something like that anyway with port forwarding/masquerading/vpn if they really wanted to...

[WarWolf 0]

I see what you're saying, but if your clan were to have a ladder match with another clan a long distance away which arguably could/would have their own server too, would reduced lag not be useful in that scenario?  I have participated in some horribly lagged clan matches in the past, to the point of folks teleporting around in front of my sights, usually just after firing too.....

EDIT: I didn't actually mean for a server to route additional traffic, just the traffic to/from it's actual connected players - and respond to those that are in the same game via their other dedi-server(s).  

Basically I mean the optional ability to link dedi-servers together for better performance....

ie the server would only route traffic for games that it's connected players were actually participating in....hope that makes it clearer?

[benu 1]

After thinking a little more about this i don't see any sense in this at all. Sure i only have my small dsl connection, but from the first hop i am in the internet, at the server of my isp. From there on nothing will change my ping to a server, regardless of where that server is located. If i play on an american server from europe the ping will not get better if i connect to a european server and that communicates with the american server or if i connect directly to that server. And bandwidth will not be bigger also, as this is limited by the smallest link anyway (which is most probably my dsl upload/download anyway), and if that link is not my first hop it will be the same bottleneck for the server.

The only difference i could see is if the two servers could kind of collect several gamestate changes from several players and throw away the duplicates. But this would not reduce latency and bandwidth shouldn't be the problem anyway, as the bottleneck will most the first hop of the players.

And even if this did work i don't see WHO would use it. I could only see 2 target audiences: big clans with multiple servers on different continents who could do this on a permanent basis and temporary connections for league games.

[mahuja 12]

The concept is very much like IRC servers. For most any large irc network, the peer-to-server traffic is staggering, and could not have been handled by a single server.

However, this is useful only under one or more of these conditions:

1) Large usernumbers

2) Transcontinental (or other internet backbone) bottlenecks

3) Lan-to-Wan connection bottleneck.

And there's the administrative overhead, highlighted by some of the other critics.

The first is typical of large-scale (MMO) games. The second is not a very big problem anymore (between eu and us anyway).

The third is useful for when people on a lan would want to join a game together, but have a limited connection to the internet. Having a "hub" on either side of the bottleneck would always be a help.

Some of the same principles are used for programs like HLTV and similar. The one most important function is that the spectators will draw the bandwidth of the hltv.exe running box (which has 1 + spectators connections transferring game data) while the server itself requires only players + 1, instead of players + spectators. The delay usually imposed for anti-cheating reasons is secondary.

[mahuja 12]

My personal opinion for this is that it is a good idea.

Especially if it was limited to a "hub" type. (Though that has possible cheating problems too.)

Bbut the administative overhead of setting it up (security/anticheating reasons would demand the admins of both servers cooperated on it, unless it was strictly a "hub") makes it 'costly' enough that it won't be used enough to warrant a lot of time from the devs.

[benu 1]

Actually, the only bottlenecks you could do something against are 1) the first hop of the user or 2) the first hop of the server. And everything else you can not influence at all, most routers will not accept source routing or similar techniques.

This idea does not change the first hop (to my isp) If i got a 70ms ping to my isp nothing will change this, except if i change my isp. I will have 70ms plus the rest of the route to ALL servers, with the rest of the route being negliable if you select a server near to you. From my experience, if you choose a server near you, the first hop is really all that counts, the rest of the route is less than 20ms. I just made a traceroute to our server, my first hop is 60ms and the whole route takes 75ms. We got players with pings of 15ms on the server.

The connection of the server is determined by the server provider, eg 100mbit nic to 6.4gbit uplink in our case. After that it's the same as above, as you can not really select which route to take through the internet.

The only possible difference would be if several players used the a) the same server to log into and b) joined the same server. Then MAYBE you could send data that is THE SAME FOR ALL PLAYERS only once. But this would only effect the traffic between the servers, not the traffic to the clients. And as those are the bottlenecks anyway nothing is gained. Besides, i don't even believe this is possible as the overhead would be too high to gain a performance gain on the client side.

And you can not compare this scenario to HLTV or IRC at all, HLTV is only one-way, regardless of whether multicast is used or not and irc is some kind of a "distributed server", which ofp is not and should not be.