TimeoutDisconnect happens almost everytime in my game

Hi,
I recently released my game in Google Play in Singapore and Philipines and I'm having lots of problems when players search for a game because almost everytime this error shows up:
TimeoutDisconnect while connecting to: ns.exitgames.com:5058. Check if the server is available.

I also get this error myself in the unity editor when debugging the game (I'm in Spain) I would say 5 of every 10 times.

What could be causing this error?

thanks

Comments

  • Hi @albergr91,

    Thank you for choosing Photon!

    Singapore and Philipines
    What region is used in this case?
    when debugging the game
    if by debugging you mean breakpoints and such then this is expected. Read more here.
  • I've been wondering if there was a way to disable the timeouts as it makes debugging very difficult when you can't really hit breakpoints and step through things. I looked at that link but I keep getting disconnected when it tries to get the room list. I don't have a static IP so I'm using the private 192.168 address for the IP and have also tried the loopback 127.0.0.1 address but both cause a disconnect. Not being able to debug is a really big problem right now.

    Can you advise as to how we can keep Photon from timing out?
  • Hi @strangegames,

    Our debugging guide is only for TCP and self-hosted.
    There is nothing you can to prevent client timeouts when debugging client connected to Photon Cloud expect reconnecting when it happens.
  • Hi John,

    Thanks for the info. Honestly, this is a pretty big problem and something I wish you all would find a way to address. It makes development very difficult when you can't use a debugger.
  • Hi @strangegames,

    Our customers use a self-hosted Photon Server during the development phase.
    Try that, it's easy.
  • Running a dedicated server because there isn't a default timeout setting seems a bit of overkill but thanks for the suggestion.

    However we are looking to move from 16 player matches up to much larger scale matches (50+) and I know we need to go to a client/server architecture to do that. Since you mentioned the servers, I wanted to ask if there is a server product that would allow us to use a client/server architecture. From what I understand, PUN is peer-to-peer. For things like position updates, what we want is the player to send their position to the server and the server to re-broadcast that out to all connected players in the game.
  • JohnTubeJohnTube mod
    edited June 18
    We simply cannot allow a leaner timeout window for clients on the cloud.

    PUN is peer-to-peer
    PUN and all Photon products have a client/server topology/architecture. Everything goes through a server. In case of PUN (and Photon Realtime, Photon Voice) everything goes through dedicated servers hosted in regional clusters around the world.
    Maybe the Master Client concept is misleading you.
    Or maybe you want an authoritative server logic, in this case, you will need to have custom server logic, we recommend Photon Plugins in this case.
  • I'm pretty experienced in network programming (used to do low level sockets programming) so no it's not a case of not understanding the master client. I went back and re-read the e-mail from your support group and it seems I had misread what they said. They had said 64 players would be a stretch but didn't say why.

    Am I correct to understand then that with PUN, when a client sends any messages, they are only sending packets to the server and not directly to other players? If that's the case, I would think you're limiting factor would be server speed and network throughput which I'm guessing your cloud has plenty of. What's going to be the limiting factor with PUN then?

    We wrote our own network backend when we made games for the 360 and it was peer to peer so we cycled through players and sent out as many position updates a frame as we could, kept track of who we still needed to send to, etc.. because we had no server to do this for us. If PUN is not Peer to Peer, then we're already doing some things we don't need to like queueing messages for individual players and breaking those up over several frames. If it's client server, we should just send one message to targets.others and let the server redistribute. Is this correct?
  • JohnTubeJohnTube mod
    edited June 18
    Am I correct to understand then that with PUN, when a client sends any messages, they are only sending packets to the server and not directly to other players?
    Yes correct.
    What's going to be the limiting factor with PUN then?
    You mean why we can't keep clients connected forever? because each client has one peer connection and all the resources that come with it reserved on the server side which costs when you multiply it...

    If it's client server, we should just send one message to targets.others and let the server redistribute. Is this correct?
    Sending to ReceiverGroup.Others will multicast to all other actively joined actors yes. You can, however, target fewer actors using the other options. It all depends on your use cases and how much bandwidth/CCU messages/room you consume/produce.
  • Ok well that's great to know. I was operating under the belief it was p2p.

    On the limiting factor, no I was talking about why someone from PUN support had said 64 players would be a stretch. That's why I thought it was peer to peer. If you're sending messages to the server and it's distributing them to other players, what's the limiting factor there? The two main factors I'm aware of in a client/server arrangement would be the server's speed in handling the messages and your network capacity to handle all the traffic and I assume your cloud has plenty of both. Trying to understand what we have to work around here if we really can't do 64 players and you're not doing peer to peer.

    On the sending to others part, since I wrongly thought we were p2p, I was keeping a list of which players needed to know about an item's status change (16 player match). Each frame, I sent a message directly to the next photon player needing the update. I had thought that sending one message with the target "others" would send out potentially 15 messages that frame ( 1 message directly to each player). To avoid what I thought would be a traffic spike that frame, I sent out one message each frame instead of 15 in the first frame. It sounds like however that we're better off sending one message to "others" since that sends the message to the server and the server sends out 15 messages to the other players. Is this correct?

  • JohnTubeJohnTube mod
    edited June 19
    what's the limiting factor there?
    What you mentioned are the limiting factors.


    Photon Cloud plans have three limits to guarantee a good service for all customers:

    1- CCU/App/Month
    2- Bandwidth/CCU/Month: (PUN and Photon Realtime: 3GB)
    3- Messages/Room/Second: (PUN and Photon Realtime: 500)

    For 1 you can optionally enable bursts.
    For 2 you can pay for overages.
    For 3 it is a soft limit you can exceed it but we highly recommend you don't to not affect other apps running on the same servers. So we will notify you and tell you to fix it if it is the case.

    If you do the math for rooms of 64 players:

    If you send to others only 10 times a second then you will exceed the 500 soft limit.
    10 * 64 = 640 > 500.

    It sounds like however that we're better off sending one message to "others" since that sends the message to the server and the server sends out 15 messages to the other players. Is this correct?
    Yes correct. Sending 15 messages to 15 players means 30 messages total (1 client to server and 2 server to client). Sending 1 message to 15 players means 16 messages total (1 client to server and 15 server to clients).
  • Ok so really we shouldn't see any difference in running 16 players or 64 if we're sending to "others", we just have a server resource issue to account for. Our network code is already pretty optimized as far as how we compact data and only send absolutely necessary items so the bulk of our messaging is really position and animation states.

    We're using transformView and animatorView components to sync the players up. I know these only send updates when values change but if the player is in a constant state of change, do you know how many messages these generate per frame? I didn't know if they send every frame and if Photon combines these under the hood.

    We use RPC's for our messaging and wanted to ask if each RPC generates a message or if these are collected and combined by Photon.

    I'm thinking that if each RPC counts as message, we'll be better off creating one end of frame RPC and packing it with all the data from our current set of messages. It would be the same amount of data so bandwidth limits wouldn't be affected but this would supposedly get our message count down.

    Thanks again for all the info.
  • do you know how many messages these generate per frame?
    See PhotonNetwork.sendRate or PhotonNetwork.sendRateOnSerialize.

    We use RPC's for our messaging and wanted to ask if each RPC generates a message or if these are collected and combined by Photon.
    I think this is not available yet. See this discussion here.

    Feel free to search the forum or the internet about Photon questions (Unity forums/answers or StackOverflow or other StackExchange websites may contain answers as well).
Sign In or Register to comment.