Client works on localhost, but not over wifi

When I run 2x clients on the same PC, everything seems to work right. I do 2 executions on one PC, have one host, and have other client connect and input "localhost" for the ip and game works great. Game works 100% as intended.

But if I try to do it with two different PCs over my home network wifi, the client game is messed up. Units are in the wrong spot, things don't spawn. It's really weird.

Any idea on some methods I could try to correct this kind of strange behavior? Maybe adjusting max buffered packets or changing the Max Delay? Or something like that?

 

In troubleshooting this the first thing I would do is have both computers wired to the network instead of using wifi. The issue you described could be coming from high packet loss for example.

 

Ok Joe I'll do this over 2 PCs connected via a hardline on the LAN and then report back.

 

Ok tested it for quite a while. Absolutely zero issues when on hard-line LAN. Problem only shows up when using wireless connection on the same home network. Are there any settings that can be adjusted in the network manager to try and alleviate this problem?

 

There are potentially quite a few reasons why you might be having problems here. Firstly, never ever rely on local testing when building a networked application as an accurate representation of how it will function over a remote connection. Locally, you will have near-zero latency (messages will be sent and received within just a few milliseconds) and near-zero package loss due to the fact that queues/buffers and other internal mechanisms will function highly efficiently, because messages get processed far quicker than they queue up.

In a high-quality environment, where your client and server are geographically close to each other, and both sides have high-quality hardware and internet, you would expect a minimum of around 50 milliseconds. That means that best-case scenario, the time that it takes to send messages over the network in a remote scenario can be 10-20 times worse than your local setup. With wifi, not only will the average time that it takes to send a message rise up into the hundreds/thousands, but it fluctuates a hell of a lot due to the naturally unstable connection.

So ultimately, it sounds like you have been relying too much on your local setup in testing your game. Now would be a good time to start basing your development on remote testing, or using the "simulation" functionality of unet (to simulate latency/package loss. Currently not working in 5.6 but should be fixed soon). To list a few things you can look into:

• in your local setup, an "unreliable" channel would almost function like a reliable channel, in that it would have been VERY unlikely that a message wouldn't have been delivered. In a remote setup, you can expect anything up to 50% package loss over wifi. So if things like spawning objects or the other issues that you've mentioned are done over an unreliable channel, you might need to think a little more about this
• in your local setup, messages would almost always arrive in the order that they were sent, due to the latency almost always staying the same. In a remote setup, the more unstable the connection is, the more likely that it is that messages will arrive on the other side in the wrong order. This can cause problems if for example a message is sent to spawn an object immediately before a message is sent to unspawn it, and the unspawn message arrives first. Using a "sequenced" channel can help with this, if you're not using one already.
• make sure to be debugging your server and client side. Check the output/player log files generated by unity. Unet is pretty good now at reporting any issues that your setup might be having. For example if messages are piling up too fast because of latency, you'll get errors like the NoResource error. So make sure you are checking the logs etc

Hopefully this helps. Good luck!

 

Thanks for the reply Donny. My issue is specifically with network id'ed game objects in the start of a scene.

From what I understand:
-Any network id components in a scene are basically inactive until a host connects.

-When a host connects, any game objects with an attached network id are spawned on both the Host's server and the host's localclient.

Some times when I connect as a client over wifi, the positions / data associated with these initial in-scene network ID game objects are messed up. They are correct on the host, but they are goofed up on the client's end.

So my question is basically, what methodology can I use to make sure the initial network id'ed game objects in a scene are received properly and in their entirety on a client, accounting for network issues arising from imperfections in a wireless wi-fi connection?

Since this is something that's generally handled for me in UNET, when the host connects / when a client connects, I don't know what I should be doing to ensure it's successful 100% of the time. Once the game is up and running, manual spawning of new objects appear to be working 100% of the time. It's just these initial scene objects that have a network id on them that are messing up, on the client upon connecting.

Any guidance to documentation on this would be good.

As of right now I'm thinking I might need to rework my code to start up the scene with no network id'd objects, then manually spawn each of these objects individually with serialization, one at a time, to try and ensure their success, but these seems like over-kill probably a really bad way to go. What would even by the point of UNET handling these network id objects with Host / client connects if it's not reliable over internet / wifi?

 

Contrary to what Unity says, I've never seen so called "scene objects" work correctly with UNET, so gave up on them and instantiate everything with a networkidentity. I haven't tried them again in Unity 5.6, but not holding out much hope. I suspect Unity's own internal testing focuses more on instantiated objects, and probably not much on scene objects.

Other than that for remote clients, such as clients with high latency and/or packet loss, you'll want to tune them with regard to send rate and if using networktransforms there's a lot of tuning there too before they feel right.

 

Yes, it does appear that the issue is entirely with scene objects (network ID'd objects that are a part of the initial scene and not when I instantiate / spawn objects manually during game play).

I guess I'll rework my scenes to have only non-network id'd objects in them initially and then use a spawning script to manually handle spawning after the scene is loaded. Seems like a waste of work, but if it's not working right at the moment I guess I'll have to make due.

One last thing before I get to work on changing up my scenes: Any advice for preventing disconnects of the client over wifi? Is there a network manager option to allow the game to be more lenient on less-stable connections?