P2P justification?

The game has to create dynamic instances handling the kind of network data that allows your computer to pass/receive information about every moment to moment position of ships and weapons. You can't compare it to games that create single instances of arena combat without being aware of what that means for a game like this, any number of instances requiring some serious server power.

A client to server architecture doesn't magically solve those kinds of challenges. It may assist with some, such as authentication/cheat detection. However it doesn't automatically prevent lag and you still have to deal with slow connections between players and server. It still requires some seriously bespoke development to make a game like this load you seamlessly into instances without hanging around in a lobby screen as you move between instances.

In computer science distributed systems are seen as a good thing. There is nothing inherently wrong with P2P as many automatically seem to assume.
 
The problem is the always online requirement.

We could have private servers (pirate copies aside) with almost no instances and lag.
 
Its really really simple and is based on how the game works

4000000000000 systems 100000 in an inhabited sector

there is no need for a server to control everything because basically we are alone - I haven't seen another player for about a month now since easter I am probably in single figures.

Setting up player controlled instances when we eventually do meet is by far the most efficient method
 
One day, in the dim and distant future, Frontier may close its own Elite servers. The P2P design may help any stalwarts set up their own Elite network somehow. So it's not necessarily all bad news.
 
One day, in the dim and distant future, Frontier may close its own Elite servers. The P2P design may help any stalwarts set up their own Elite network somehow. So it's not necessarily all bad news.
I think that was one of the reasons P2P was choosen. They still ended up with a game that can't run without servers and some bloated server code that they cannot release, so it probably won't work this way and when FDev goes out of business we will have to rely on the hacking community to revive their games, similar to what happened to Elite 2 and 3 :)
 
Sorry, you've gone off on a wild tangent about "using" uPnP... as if something could "use" the uPnP mechanism for actual data transfer itself between the clients.

Huh? My understanding is that FD uses uPnP as part or all of the transport layer for game peer-to-peer communications. Is that incorrect? If that is incorrect then obviously what I said about uPnP is irrelevant.

There are design flaws in using P2P and many of the people arguing against server-centric communications are assuming that performance is a concern (it is, but only if coded by idiots) if FD used uPnP then it's worth understanding that performance would likely improve dramatically using a server-centric architecture, assuming it wasn't coded by utter boneheads. But what's relevant is that if FD is using uPnP then utter boneheads is exactly what we're talking about.

So if you see all that as a tangent, do you actually understand the situation?
 
Last edited:
with no ongoing financial revenue streams such as subscription, there is no justification for a client-server approach. When the Xbox CQC and the already allowable Open mode are used, Xbox players are actually paying Microsoft money for what is essentially is a free service (P2P)
 
UPnP is used as the connection establishing protocol, in order to get Elite clients talking to each other via the matchmaking server. Elite gameplay packets themselves are UDP. There is some HTTP traffic as well for what I assume to be Galnet and calls to the FD store via a browser. I wasn't actually looking at the screen and thought "wow FD coded an ingame browser?" and then imagine my disappointment lol :D
 
UPnP is used as the connection establishing protocol, in order to get Elite clients talking to each other via the matchmaking server. Elite gameplay packets themselves are UDP.

Ah, Ok. That's better, then.

So, the networking "could be worse" - still, make a comparison between some kind of straight-up data over TCP versus xml-over-anything, and it'll scare you. It's an insane design decision to use that flup for anything at all.
 
Last edited:
Back
Top Bottom