Going fullscreen kills Photon?

sebastian
edited July 2011 in Photon Server
The client gets disconnected when we toggle to fullscreen mode. I've built the webplayer and get the following errors:

Client:
web: set web resolution 1024 x 768, fs=1
Info: command was received before! Old/New: NC(0|8 r/u: 749/0 st/r#/rt:0/0/0)/NC(0|8 r/u: 749/0 st/r#/rt:0/0/0) inReliableSeq#: 746 first in queue: NC(0|8 r/u: 747/0 st/r#/rt:0/0/0)
Info: command was received before! Old/New: NC(0|6 r/u: 750/0 st/r#/rt:0/0/0)/NC(0|6 r/u: 750/0 st/r#/rt:0/0/0) inReliableSeq#: 746 first in queue: NC(0|8 r/u: 747/0 st/r#/rt:0/0/0)
[... more of the same warnings]
Info: command was received before! Old/New: NC(0|8 r/u: 758/0 st/r#/rt:0/0/0)/NC(0|8 r/u: 758/0 st/r#/rt:0/0/0) inReliableSeq#: 746 first in queue: NC(0|8 r/u: 747/0 st/r#/rt:0/0/0)
Server sent disconnect. PeerId: 2 RTT/Variance:23/11
StopConnection()

The returncode in PeerStatusCallback(): DisconnectByServerLogic

Server:
2011-07-08 12:25:26,915 [15] WARN WOFGameServer.WOFGameServerApplication [(null)] - disconnecting peer 2: Send buffer full

It seems like the update loops get called (i.e. the warning), but apparently the peer.Service() doesn't send/receive while Unity is switching to full screen!?

Any ideas/suggestions?

Cheers!

Comments

  • Switching to fullscreen should usually not do anything to the running code. Also, it does not take more than a few seconds.

    The "Send buffer full" entry in the server log points to an issue, where you try to send more data than possible due to flow control. This will also disconnect a peer. Most likely this is your problem.

    Check what you are sending in a short amount of time. Stretch it out.
  • Tobias wrote:
    ... you try to send more data than possible due to flow control. This will also disconnect a peer. ...
    Is there a doc or settings about flow control?
    What is the data limit that can be send? (per cycle? per sec?)
    Is the limit per photon instance? per peer?
    is the limit by size? or/and by number of events/responses?

    Btw what happen to message send to a disconnected client?
    Will they accumulate until the peer is disconnected()?

    I could only find this in the doc:
    PhotonPeer.SendOutgoingCommands Method
    "A tradeoff, an application will lose connection, if it is no longer calling
    SendOutgoingCommands or Service ( see page 34).
    If multiple operations and ACKs are waiting to be sent, they will be aggregated into one package. The package fills in this
    order: ACKs for received commands A "Ping" - only if no reliable data was sent for a while Starting with the lowest
    Channel-Nr: Reliable Commands in channel Unreliable Commands in channel
    This gives a higher priority to lower channels.
    A longer interval between sends will lower the overhead per sent operation but increase the internal delay (which adds "lag").
    Call this 2..20 times per second (depending on your target platform)."


    And this
    PhotonPeer.CommandBufferSize Property
    This sets only the initial size. All lists simply grow in size as needed.
    ...
    Configure the WarningSize ( see page 39), to get callbacks when the lists reach a certain size.
    What should we do if we get a WarningSize() ?
    Call Service() at least. But should we limit the number of send messages until the heap decrease at an acceptable level?
    Some sort of "don't send unimportant message" flag?
  • Getting a warning about the size of the sendqueue is normally a symptom, that your game is in generally sending to many or to big operations or calling service()/sendOutgoingCommands() not often enough. If you just drop some messages, when you already triggered the warning, than you are only fighting the symptoms instead the real problem.
    You should check, how often you are calling some operations and how big they are and how often you are calling service()/sendOutgoingCommands().
    For every call on these functions they send out 1 command (only, if there is anything waiting to be sent at all, of course, including pings). So if between 2 calls to these functions you are putting more data into the sendQueue, than can be sent out with one command, the queue will increase. If this is the case most the time, than the queue will increase above the warning-size. Nothing will be dropped, but if you put anything new in this queue, it will take some time to be sent, as all earlier entries are still waiting to be sent.
    It depends a bit on the client-platform, but the usual maximum size of a command is about 1.2kb. As there always is some overhead for data structures, you can assume about 1.000kb for payload. So if you for example call service() once per frame and send out a 50kb-image every 10 frames, than you are filling the queue ten times faster, than it can be emptied and will get this warning after a very short time.
  • lazalong wrote:
    Tobias wrote:
    ... you try to send more data than possible due to flow control. This will also disconnect a peer. ...
    Is there a doc or settings about flow control?
    Flow control can be configured on the server.
    Look at the "Throtteling" section in the photon-configuration.pdf that can be found in the doc folder of the server SDK.
  • Thanks for the info.

    I know see I will need to design my application carefully with different channels.
    At least one for unimportant and can-be-delayed message (such as players images, big list of market orders, list of assets and such).

    PS: Perhaps renaming the title of the thread might be more informative of the thread content.
  • Kaiserludi wrote:
    For every call on these functions they send out 1 command (only, if there is anything waiting to be sent at all, of course, including pings). So if between 2 calls to these functions you are putting more data into the sendQueue, than can be sent out with one command, the queue will increase.

    Not this is interesting. I thought the entire queue was cleared. This actually explains a lot.

    We do send lots of data (about 30 times / second), but haven't had issues with it in our normal update loop yet. Toggling full screen apparently holds off updating until the screen is in its new state, and that is enough to fill the queue beyond the point where we can recover.
  • Kaiserludi wrote:
    For every call on these functions they send out 1 command (only, if there is anything waiting to be sent at all, of course, including pings). So if between 2 calls to these functions you are putting more data into the sendQueue, than can be sent out with one command, the queue will increase.

    Now this is interesting. I thought the entire queue was cleared. This actually explains a lot.

    We do send lots of data (about 30 times / second), but haven't had issues with it in our normal update loop yet. Toggling full screen apparently holds off updating until the screen is in its new state, and that is enough to fill the queue beyond the point where we can recover.