the maximum timeout that we can set?

xzlxt720

I got a exception on line33 when i set maxtimeout value to 65000, and how to solve this?

[code2=plain]8824: 11:10:13.283 - ---
8824: 11:10:13.283 - Service: "Photon Socket Server" starting
8824: 11:10:13.283 - Config File: \workspace\ExitGames-Photon-Server-SDK_v3-2-10-4248\deploy\bin_win64\PhotonServer.config
8824: 11:10:13.284 - Will produce at most: 10 crash dumps
8824: 11:10:13.284 - Action: run as exe
8824: 11:10:13.284 - Server Starting...
8824: 11:10:13.284 - Tick count: 4053233 (wraps in: 49.6634 days)
8824: 11:10:13.285 - Tick count 64: 4053233
8824: 11:10:13.285 - Photon Version: 3.2.6.2037
8824: 11:10:13.285 - PID: 8268
8824: 11:10:13.285 - Config File: \workspace\ExitGames-Photon-Server-SDK_v3-2-10-4248\deploy\bin_win64\PhotonServer.config
8824: 11:10:13.293 - Not using performance counters. The installed counters do not match the counter dll
8824: 11:10:13.293 - Run the service with /InstallCounters to reinstall the latest counters.
8824: 11:10:13.293 - Max message size: 512000
8824: 11:10:13.294 - S2S: MaxInboundMessageSize: 512000
8824: 11:10:13.294 - S2S: MaxOutboundMessageSize: 512000
8824: 11:10:13.294 - S2S: No inactivity timeout
8824: 11:10:13.378 - WebSocket S2S: MaxInboundMessageSize: 512000
8824: 11:10:13.378 - WebSocket S2S: MaxOutboundMessageSize: 512000
8824: 11:10:13.378 - WebSocket S2S: No inactivity timeout
8824: 11:10:13.379 - Max Reliable Data In Transit (awaiting ACKs) per peer : 51200 bytes
8824: 11:10:13.379 - Per peer bandwidth limit
8824: 11:10:13.379 - Transmit Rate Limit: 256 KB/Sec
8824: 11:10:13.379 - Limit period: 200ms
8824: 11:10:13.379 - Limit per period: 52428 bytes
8824: 11:10:13.379 - Max queued data for transmission per peer: 512000 bytes
8824: 11:10:13.379 - Minimum retransmit timeout: 200
8824: 11:10:13.379 - Minimum ENet timeout: 5000ms
8824: 11:10:13.379 - Maximum ENet timeout: 65000ms
8824: 11:10:13.379 - Max Inbound Reliable Data Queued (awaiting resends of earlier sequence numbers) per peer : 163840 bytes
8824: 11:10:13.379 - Outbound ENet: MaxInboundMessageSize: 512000
8824: 11:10:13.379 - Outbound ENet: MaxOutboundMessageSize: 512000
8824: 11:10:13.379 - CService::OnException() - Exception: TENetHostBase<Peer>::TENetHostBase<Peer>() - Max timeout is too great for supplied timer wheel
8824: 11:10:13.379 - Server shutting down...
8824: 11:10:13.379 - Shutting down WebSocket Outbound Connection Manager...
8824: 11:10:13.379 - Shutting down TCP Outbound Connection Manager...
8824: 11:10:13.379 - Shutting down socket servers...
8824: 11:10:13.379 - Shutting down ENet thread pool...
8824: 11:10:13.379 - Shutting down TCP inactivity timers...
8824: 11:10:13.380 - Shutting down business logic thread pool...
8824: 11:10:13.380 - Shutting down I/O thread pool...
8824: 11:10:13.380 - Destroying servers
8824: 11:10:13.380 - Destroying WebSocket Outbound Connection Manager
8824: 11:10:13.380 - Destroying TCP Outbound Connection Manager
8824: 11:10:13.380 - Destroying TCP inactivity timer
8824: 11:10:13.380 - Destroying ENet timer wheel
8824: 11:10:13.380 - Destroying ENet host
8824: 11:10:13.380 - Flushing ENET buffer allocator...
8824: 11:10:13.380 - Flushing TCP buffer allocator...
8824: 11:10:13.380 - Flushing TCP buffer handle allocator...
8824: 11:10:13.380 - Flushing stream socket allocator...
8824: 11:10:13.380 - Flushing inbound datagram socket allocator...
8824: 11:10:13.380 - Flushing outbound datagram socket allocator...
8824: 11:10:13.380 - Destroying CLR dispatcher
8824: 11:10:13.380 - Destroying CLR applications
8824: 11:10:13.380 - Destroying ENet thread pool
8824: 11:10:13.380 - Destroying Business logic thread pool
8824: 11:10:13.380 - Destroying I/O thread pool
8824: 11:10:13.380 - Destroying ENet buffer allocator
8824: 11:10:13.380 - Destroying TCP buffer allocator
8824: 11:10:13.380 - Destroying TCP socket allocator
8824: 11:10:13.380 - Destroying ENet inbound socket allocator
8824: 11:10:13.380 - Destroying ENet outbound socket allocator
8824: 11:10:13.380 - Scheduling performance counters for atexit destruction
8824: 11:10:13.380 - Shutdown complete...
8824: 11:10:13.380 - Service shutting down: with Exception (1). Errorcode: 6
8824: 11:10:13.381 - Service shut down complete[/code2]

[Deleted User]

The max. allowed value is 60.000 (1 minute).

sparr0w

Is this still the case as of now? Is there a specific reason for such a short timeout range?

[Deleted User]

Yes, this is still the case. And honestly, I don't see a use case where this is too short.

Photon sends a "ping" to a client in short frequencies. A client acknowledges that it has received this data (it sends back an ACK). This is not necessarily related to any operations etc. - it is just a very low-level "connectivity check".

The ENET timeout specifies the max. timespan for which Photon waits for an ACK for its ping. If an ENet client is not able to send a single ACK for a whole minute (!), there is a serious network issue - i.e., the client is disconnected.

There is no need to send operations / data every minute. Your client can be "idle" for several minutes, as long as it is able to send ACKs regularly.

Does this help, or is there a use case for which you absolutely need to have larger timeouts? We are always interested in your use cases, so that we can improve Photon to match your needs - so if you can convince us that a change is useful, we are always willing to make that change.

sparr0w

Hey, thanks for the info

Well, I'm not exactly sure if there is some better way of handling my case, maybe you're able to offer me a better way

This current game will be iOS/Android only. Upon player connect the server generates a random map with a fixed amount of enemies from a random pool. Should the player close the map while he is midgame, I'm currently saving the map and all enemy types into a Database. The states get nulled however, because it would be beyond me as of how to restore the scene - say - in the middle of an animation.

This basically means if the player quits and then opens again he will be placed on the exact same map, but at the start.

Now I have a problem with players, who only want to quickly check their emails or whatever. Usually I would just pause the game for say up to 10 minutes here. If he would open the game again within 10 minutes the game itself will continue as per usual.

With a timeout setting of 1 minute however, every home screen press with a stay on the home screen for longer than 60 seconds needs to be treated as a full quit.

This is basically the reason why it would be beneficial to me to allow longer timeouts. Obviously not absurd ones, but 10 minutes or something like that would be great

All of that is just for the single player (cheat protected) aspect of the game. As for the multiplayer, 60 seconds timeout is very fine!

Do you have any hints for me?

Sidequestion: I'm getting 3 "Embed Interop Types" Warnings in my solution (for lite.dll, litelobby.dll, photon.socketserver.dll), how can I address this issue? Or should I just ignore it? The game runs perfect, even with the warnings.

Thanks a lot!

Tobias

Obviously it is possible for messengers and similar app types to keep connections in the background of iOS and Android.
The Photon Clients don't make use of such a feature however and can't send anything while in the background. The clients will time out the connection after not receiving something for a while (they will notice the passed time when they get focused again).
You can raise the timeout time and the re-send rate but ultimately it's a very messy approach.

Instead of keeping the connection, you might keep the state on the server side and enable re-joining the room after a disconnect. You can time out a room if it's empty and save it after the time is up.
You probably don't have to sync all animations anyways. Just keep the positions and most vital info and on re-join a player can go on from where he was.

Kaiserludi

Tobias wrote:

Obviously it is possible for messengers and similar app types to keep connections in the background of iOS and Android.
The Photon Clients don't make use of such a feature however and can't send anything while in the background.

I have to correct my colleague here.
"In iOS, only specific app types are allowed to run in the background:

Apps that play audible content to the user while in the background, such as a music player app
Apps that record audio content while in the background.
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
Apps that implement these services must declare the services they support and use system frameworks to implement the relevant aspects of those services. Declaring the services lets the system know which services you use, but in some cases it is the system frameworks that actually prevent your application from being suspended."
https://developer.apple.com/library/ios ... 2-CH4-SW24
Running in the background to keep an udp or tcp connection alive is simply not allowed by Apple.
For that reason neither Photon nor messengers or similar app types can keep their connections alive on iOS when entering background.
Messengers like WhatsApp for example use Push Notifications to inform the user about new messages, when the messenger app itself is not running.