Disconnection Problem

I guess, you wanted to write 10 - 15 minutes, which is a long time for a conneciton without traffic to stay open - especially over the Internet.

RTC Sessions do NOT expire while being used (for example, while executing a remote function on the Server) and all Exceptions raised inside the OnExecute event will be sent back to the Client (as a Result) if the connection is still open.

A connection can either be closed by the Client, or by the Server, or by anything between the Client and the Server. While there is an "Error Code" at the lowest socket API level when a socket operation fails, the only "reason" given by the socket API is "connection reset by peer", which simply means that a conneciton was closed remotely. After that, RTC triggers a "Disconnect" event on the Server and a "ConnectLost" and/or a "Disconnect" event on the Client, depending on the previous state of the connection. In other words, there is no specific "reason" given by the low-level API for a disconnect (only that a connection was closed).

In some cases (usually in congested and/or slow networks, or in case of a physical disconnect) it is also possible for a connection to be closed by one side, without the other side being notified that a connection was closed. This is why Timeouts are used in combination with TCP/IP to close connecitons without traffic. APIs used for communication have predefined Timeouts to close connections without traffic and use relatively low default Timeout values (usually 60 seconds). Before a connection has been established, most API Timeouts can be changed by using the "TimeoutsOfAPI" properties (available on TRtcHttpClient and TRtcHttpServer component), but ... if your connection is established over the Internet, you also need to take Proxy Servers and some Routers into account, which could also close the connection when there is no traffic for some time (usually after 30 - 60 seconds).

Connections can also be closed when there is TOO MUCH traffic - as a result of Network congestion control, which is implemented at the lowest TCP/IP layer and is NOT under Application control. For example, if all your Clients would start continuously sending requests to your Server without waiting between each request, even if these requests were very small (for example, only sending a PING), the Network would eventually exceed its peek capacity and TCP/IP packets would start being dropped. At first, this would result in a Network slow-down, but then connections would also start being closed.

A connection can also be closed by the Client if you set connection Timeouts (for example, by using the "Timeouts" property on the TRtcHttpClient component) and the Server takes longer that the last Timeout specified to execute the function and prepare a Result for the Client.

In a nutshell ...

Unless you are in full control of the entire Network where your data is passing through (which is NOT possible outside of your LAN), you should NOT expect connections to stay open for longer than 30 seconds when there is no traffic going in either way, and ... you should avoid flooding the Network with a lot of traffic to avoid network congestion, since that can also result in disconnects.

If your Server takes several minutes to finish executing a remote function call, to reduce chances of a connection closing before a Result was sent back to the Client, you will either have to split that function into multiple smaller parts, each finishing within a relatively short time period (for example, in less than 30 seconds), or ... implement some kind of a processing queue on the Server, so that your Clients can add new jobs into that queue, get a short result immediately as "acknowledgment" of a job queued, then periodically check their job status (queued / started / finished) and get the "data" when the job has finished. For example, using delayed calls to get short responses while the Server is working and then getting the result data when it is ready.

Best Regards,
Danijel Tkalcec