- Home /
Host Migration Solution
Hi guy's been searching again for this host migration thing and this is what i've found.
This solution uses the version of Network.Connect that takes a GUID. It has taken a fair amount of effort to implement/test/refine (the last few weeks) and unfortunately entails a lot of application specific code, but at least it is possible.
I've revised my original answer below. This is strictly using Unity's networking system:
Each player communicates his GUID (Network.player.guid) via a buffered RPC to everyone in the session when he joins -- send it along with the details about the player's avatar (color, name, etc).
Every player locally now has a list of all the other player GUIDs in the session. This is the host candidate list, used to choose the next host when the current host disconnects.
The host candidate list must always be sorted in a way that guarantees an identical order on every machine. You can sort the list by the NetworkPlayer id, or it could even be sorted by GUID. You could also just have the current host dictate the order. Ideally, though, the sort would also take into account the NAT type, so players with greater NAT compatibility are at the top.
Now, if a client loses connection unexpectedly, he does one of two things:
If he is next in line to be host, he immediately initializes and registers a new server.
The other players wait a second or so, and then call Network.Connect( nextHostGUID ). This connects directly to the new host via the facilitator, bypassing the need to poll the master server for a list of games.
The client attempts to join the host a couple of times before giving up. He then repeats this using the next host candidate in the list. Eventually everyone will either connect to a new host, or end up hosting a new game locally.
(caveat: To connect to hosts that have no NAT and therefore possibly not registered with the facilitator, you MAY need to poll the master server for a host with the desired GUID.... It may also be possible to just always force migrated hosts to useNAT, so he registers with the facilitator. I don't have a machine without a NAT, so I've not been able to test this case yet.)
In the best/typical case, everyone will be reconnected after a few seconds of waiting. The new host can determine that everyone is reconnected by checking any new joiners against the host candidate list.
Once everyone is reconnected, it's time to migrate the networked game objects over to the new session. The original NetworkViews are no longer valid in the new session. So the old NetworkViews must be destroyed and then recreated with new viewIDs by the owning player, and the new view IDs must be transmitted to everyone so they can do the same. Networked objects belonging to the original host, or by any players that failed to reconnect will either need to be destroyed or assigned new owners (I personally have gone with the destroy approach).
I recommend pausing the game during this whole process, so unfortunately not completely seamless. You may or may not find that is necessary, but bear in mind syncing will be broken until everyone is reconnected. If you do pause, the host can send out a synchronized time of when to resume gameplay.
And there you have it... a migrated session. Your details may differ some based on your network architecture (my game has each player authoritative over their own state), but I think the basic approach will work regardless.
Can anybody simplify this for me.All i understand from this is that 1.Make a host candidate list(It will choose which player becomes the host next in order) 2.The new host will create a server if the old host leaves and will call all the other players to connect with call Network.Connect( nextHostGUID ).
I dont understand this part
(caveat: To connect to hosts that have no NAT and therefore possibly not registered with the facilitator, you MAY need to poll the master server for a host with the desired GUID.... It may also be possible to just always force migrated hosts to useNAT, so he registers with the facilitator. I don't have a machine without a NAT, so I've not been able to test this case yet.)
I dont understand this part too.
Once everyone is reconnected, it's time to migrate the networked game objects over to the new session. The original NetworkViews are no longer valid in the new session. So the old NetworkViews must be destroyed and then recreated with new viewIDs by the owning player, and the new view IDs must be transmitted to everyone so they can do the same. Networked objects belonging to the original host, or by any players that failed to reconnect will either need to be destroyed or assigned new owners (I personally have gone with the destroy approach).
Will anyone help simplify this.I know this question may be a little complex but i hope all of you cant understand.Thanks
Answer by Bunny83 · Jul 06, 2014 at 09:53 AM
Something like that can't be "simplified". It's actually more complex than you wrote there. You need a way to actually match up objects which were linked by an NetworkView previously. I would suggest to give every NetworkView a script that holds a GUID which identifies this NetworkView. Depending on how important security is for you, you either have every player (once connected to the new host) to create a new ViewID for every NetworkView he owns and then announce ViewID updates through a "global channel", or have the new server manage everything and ask specific players to generate new ViewIDs for his objects and the server will announce them to the others.
The "global channel" could be a host-migration-prefab with a NetworkView which is Network.Instantiated by the new host.
Your "question" seems a bit, well, strange... It looks like you tried to quote someone else but haven't marked it in a way it's clear what's a quote and what you actually wrote. You also didn't link a source for your quotes.
I'm not sure what you expect to get as answer.
You also shouldn't use Network.Instantiate for anything game related since it's behaviour can't be reproduced. The buffered RPCs will be lost once the server is gone. That means if a player joins afterwards it won't get the objects created. So it's in general better to manage all dynamic objects yourself.
Ya im trying to do that now. But is it possible to make everyone that joins the game a host so that if a host is gone everything will still be fine?
? I'm not sure what you mean... Do you know how a server - client connection works? One peer can only be either client or server. Every client is connected to the server. When the server leaves all connections are gone. Clients can't direct connect to each other unless one of them is a server.
can i it like this?one player is connected as server and when someone leaves immeadiately a random player becomes another server.
Your answer
Follow this Question
Related Questions
Host migration or so? 0 Answers
Where can i get the default script of the integrated host migrator in unity ? 0 Answers
Where can i get the default Host Migration Script ? (C#) 0 Answers
Automatic Network Migration Manager 0 Answers
Host Migration ? 1 Answer