So far I’m loving all ideas and approaches High Fidelity takes in setting up its framework and functionality, making everything simple efficient and stable. This is why I wanted to bring up an idea that recently popped to mind; If this is already possible, I’d like to know more about how it works… if not, it’s a feature I would like to suggest considering in the future.
What brought this to my attention is the way IRC (Internet Relay Chat) works: IRC servers rarely consist of one server, but a group of servers that sync up with each other to deliver the same content. Different users can be connected to various servers from the same network… but they all see the same channels, same users on these channels, get the same messages from one another, etcetera. You can get what is called a netsplit if two servers lose touch, which is an unavoidable disadvantage of this method.
I’m wondering whether the server components of High Fidelity could allow for a similar idea. In this case, whether multiple machines running the Hifi server tools can be configured to sync up with each other and mirror the same data. In such a way that any user can connect to any node for that domain, but everyone sees the same entities and people in the environment, whereas any changes made on the region (like adding or removing or editing entities) are instantly reflected to other servers and the players on them.
Since some people might wonder why such a system would be useful, here are the three primary advantages and reasons why I’m a fan of this technique and advocate it where appropriate:
Less lag: One of the first outcomes of this system on IRC is that, when a server is ran by multiple machines in different countries, users can connect to the node closest to them for the best speed. In our case: Let’s presume that a domain intended for English speakers is ran by two nodes, one in Britain and one in the United States. When British / European users try to connect to the domain, the main server detects their location and directs them to the British server… whereas US / American users are sent to the US server instead. Although in-world updates between British and US users will remain slower, users from the same country will experience faster responsiveness toward one another, while interactions with the world (what isn’t predicted client side) will be fastest for each side.
Decreased risk of downtimes: Let’s assume I run a node for a Hifi domain, and my neighbour runs another node. Because of unforeseen circumstances, I need to bring my server down for a day. If the domain was hosted solely by me like a conventional server, no one would be able to enter that domain until I fix my server up. But in this case, the connection server notices that my machine is down, and connecting users are directed to my neighbour’s node instead. Once my own node is back up and running, it looks at my neighbour’s node to see if anything in the world was edited, and updates my local copy of the world to reflect all changes.
A workaround to censorship: Hifi will eventually host content or ideas that laws in less fortunate countries might find a problem with. Being able to host a domain across multiple servers makes sure that, if a node in one country must go down for any legal reasons, a node in another country still exists and the domain does not disappear entirely. Unless a user’s connection to all nodes in all countries is censored, users everywhere can continue visiting that domain.
Of course, there are also threats and disadvantages to the technique. Two I can think of include:
What happens if two or more nodes for the same domain lose touch with each other, and during that time changes are made to the domain on each? For instance: Someone adds a new entity on one server, while someone removes an existing entity on the other server. When the servers sync up again, how will they know which one’s changes should be mirrored to the other and resolve this conflict? IRC doesn’t have this problem since it doesn’t store anything, it only delivers messages in realtime.
How can the administrator of the domain make sure that someone running a node can’t sabotage the data? Obviously, the best way is to only have trusted users run nodes for your domain… but being able to safely liberalize node hosting would be much more efficient in the long run. For this, one would have to make sure that a malicious user can’t corrupt data on one node and have other servers sync the broken changes from it.
What are your overall thoughts on the idea? Are there any possibilities or plans yet for this mechanism?