Host migration

[jaglitegrann]

Issue Type

Feature

Description

Implement support for host migration.

[TwoTenPvP]

To be honest, this should actually be fairly easy to implement. One just have to write a super reliable, slow syncing list of the order people should become hosts. Then with a shared timeout between them.

The difficult bit is going to be collecting all the states and syncing them.

[DatBlindArcher]

Hello, I'm interested in this feature aswell. I've been working with mlapi for a week or so trying things out, looking through the repository and it's looking like exactly what I need. Except I'm working with custom steam and photon transports that use P2P, which was pretty easy to setup. The problem however, is that when someone leaves the lobby in either steam or photon, there needs to happen some kind of HostMigration.

If you're not available to make this, is it possible to lead me in a way so I could try to add this myself? I was thinking the changes for HostMigration would be along the lines of:

Core:
- Turn a client into a host (if transport allows this without remaking it)
- Sync ClientLists
BufferMessages:
- Sync queue
Scene:
- Can fail if host leaves during sceneSwitch
- Notify if host starts sceneSwitch and reset if he leaves during
Spawns:
- NetworkingManager.Singleton.ConnectedClients[ownerClientId.Value].OwnedObjects
- Sync lists

[DatBlindArcher]

@TwoTenPvP I just want to complement your code structure. I got host migration working for 75% pretty easely. The last few pieces wont take me long. You're awesome for making this great library!

[hippocoder]

Is host migration available in MLAPI?

[TwoTenPvP]

Is host migration available in MLAPI?

Nope. Work has started on it in #338 but it has not been completed.

[styliann-eth]

Has there been any development since #338 was closed?

It would be a very helpful thing if Unity Netcode for GameObjects could have at least the transfer of the host role to another client automatically.

Boss Room could maybe have an example of host migration? Thanks!

[thetestgame]

I would be interested in knowing if there has been any development as well. Host migration could end up being a critical piece of a project currently in the proof of concept phase.

[JesseOlmer]

This feature was closed because host migration is not in the short-term plans for the SDK.

[Zee2]

This is a pretty critical feature! At least exposing hooks in the API to allow developers to write their own host migration system would be great.

[mrstruijk]

I would also really love to be able to do host migration

[JesseOlmer]

This is a pretty critical feature! At least exposing hooks in the API to allow developers to write their own host migration system would be great.

This doesn't really seem realistic to me. There are many parts of the framework itself that would need fixup in the case of a host migration and hooks wouldn't really enable that. Here's a non-exhaustive list of the types of problems that need to be addressed with host migration:

• NetworkObject Observers lists would need to be modified (to include the new host), sent to the new host, and the state of those objects would need to be synchronized to the new host.
• The ConnectedClients list and associated NetworkClient types would need to be synchronized to the new host
• The new host would have to close its transport and open a new one in listen mode, which depending on the transport may not even be possible or reasonable.
• Other clients would have to be told about the new host.
• We'd need to implement identity (authentication) for connections so the new host knows which connection belongs to which clientId
• Owner-authority variables would need a mechanism to re-synchronize any lost changes (right now we depend on the Reliable channel for this)
• Scene synchronization needs to be migrated - including during the middle of loads

At the end of the day, we have limited resources, and we're choosing to spend them elsewhere (including optimizing the dedicated server experience as we believe that is the better user experience in almost every case)