Difficult clients

Hiya,

How best can we deal with the notion of a difficult client? I'm finding it hard to research this particular area of networking, and it's as follows:

1. client can receive packets at a regular rate, other players appear smooth to client
2. client suffers a high rate of dropped packets when sending, or has large random delays when sending data.

This means while the difficult client has a great experience, other people are experiencing the difficult client ghosting or flying around as they lerp the new position of the difficult client.

This same difficult client was able to play a match of quake3 without any issues though so it's an interesting issue to solve. Any advice?

Comments

  • Sorry for the late reply. Your posts actually fell into the time we spent traveling and at Unite.

    Those freak cases are really difficult to analyze. We're beginning to put a lot more effort into that, as we realize how annoying these cases are and how much insecurity they might spread among the players.

    As first step it's probably important to analyze if the problem is self-made. Check if the Update loop is consistent (e.g. loading levels pauses Update(), so set IsMessageQueueRunning to false while you do) and if your game is not creating more traffic than it can send. In best case, you can check both on the difficult client, too. In some cases, bugs only manifest due to timing or while communicating with specific other hard- and software.

    PUN has PhotonNetwork.TrafficStatsEnabled and .TrafficStats. Once enabled you can check the longest gap in send-interval and incoming- and outgoing-bytes.
    You can also check if one of our demos runs better or shows the same behaviour.

    Two more checks could be done. These settings must could modified before you connect:
    a) PUN uses a moderate Maximum Transfer Unit (MTU) size which can be reduced to the absolute, guaranteed minimum. Set PhotonNetwork.networkingPeer.MaximumTransferUnit to 576 (bytes) and see if that improves things.

    b) Try to set PhotonNetwork.networkingPeer.CrcEnabled to true. This will discard broken packages on either side in case a router or some other piece messed with packages. Dropped packages due to this indicate problems on the network route (check PhotonNetwork.networkingPeer.PacketLossByCrc). Server-side, we would have to check for PhotonCloud.

    Do you have access to this difficult client?
  • Hi Tobias, thanks for getting back to me.

    I do indeed have full access to the difficult client, he is one of our developers working with development hardware (haswell) so we think there is a high amount of jitter with this particular hardware. It doesn't happen when he uses a different laptop from the same location. I consider it fortunate we caught this because haswell laptops are becoming the next laptop to buy for many.

    As we have access to the problem client, what do you suggest we try next?


    Thanks for advice.
  • Ok, cool you got access to that client! Then we should get in touch and discuss directly if possible. I will PM you here.

    I suggest you check the values I wrote about. You can use PUN's TrafficStatsGui to get a quick look at rtt and the "health" values (longest gap).
    Also please experiment with the two ideas I wrote about in the other post. Getting some results for those could help analyzing this.

    Edit: please check your messages in this forum. Sending you my skype id.
  • Hi Tobias, will check sorry for delay away from office at moment.
  • No need for an apology. Take your time. I'm happy you are willing to help us :)