Qualified estimation of nr of peers in a very-larg

2019-09-17 10:36发布

问题:

This question is for an indication/hunch. I realize that it may have been discussed before and that there is no good, scientific answer; nevertheless i seek for experienced/qualified opinions, as there are no definite answers to be found. An indication will be valuable as a clue, hence i ask the community to allow a bit of fuzzyness.

Background:

Consider a very-large-area 3D simulation

  • with n participants (peers, people behind NAT) distributed over multiple cities.
  • where each participant is seen as one "moving object" in the simulation (hence each moving object is owned by a peer).
  • where each peer shall see all other moving object correctly (ie. positional updates are needed).

(The entire simulation is larger, so we now focus on one single blob, and consider it to be the entire "world").

Scale:

  • World/blob size 10x10 kilometers (almost flat world).
  • Object size: Length max 10 meters

(We omit things like occlusion, optmisations, balancing etc. Assume that all there is needs to be seen and updated).

The nature of "moving object":

  • it is physically/positionally restless (compare to a boat in big waves).
  • it's movement must be sync'ed to all peers (but individual sync does not need to be simultaneus with other syncs).
  • if X sees one, but does not own it, it will behave well (deterministically, by X's local physics calculation) for maybe 1 second, but after that it will diverge (due to different frame rates) and needs a positional update (a UDP packet) from it's owner.

From a peers point of view:

  • He needs to update n-1 other peers
  • He need to receive updates from n-1 other peers

The positional updates are the critical ones, so focus only on those. One update is ca 20-30 doubles, ca. 200 bytes. Consider UDP only.

As i see it, there are two options. The first one is serverless, where everything works solely on peer2peer communication. The second one is having a server (one, for now) in the middle.

1. Serverless, p2p Each peer must talk with many other peers. One problem is that "Nagle'ing" is useless. First reason is that all endpoints are different, Second is that the local data changes from frame to frame, and there is no point in accumulating multiple frames' data, to send in a larger packet, more sparsely. The oldest frames' data would be outdated. An advantage is however not being dependant on a server.

2. Server-supported Each peer sends it's info to a high-performance, high-bandwidth server which is able to better receive and distribute to all peers, at a fast rate. Similarly, any peer would receive all peers' data from one endpoint only, the server.

Naurally, each peer runs a game loop.

Question: Hopefully based on some kind of experience, what would you throw as a maximum functional number of peers for case 1, case 2? Thx.

回答1:

It is difficult to quantify, but for such a level of all-to-all synchronization I would recomend centralized control.

In p2p mode each peer would send n-1 and receive n-1 packets each pseudo-round. In centralized mode they would receive n-1 packets, but would send only 1, spending less time in this task. So centralized mode seems to be more scallable.

A server can check if update messages are consistent before delivering them. In p2p, each peer would have to deal with instable or disconnected peers, which could be better managed by a server.

In centralized mode update-time has to be better carefully choosen, because clients are more susceptible to experience higher latencies, as each packet has to travel towards the server, and then back to the clients. Choosing the best server for clients is one thing to consider.

Combining packets could make the information traverse the network faster, but as outdating of data is an issue, try to make sure each packet is as small as possible, transmission time is smaller in this case.