Problem with Session when a Client force the disconnection

[ISIGest]

Hi, I've a small problem with Session and Client disconnection.
I use the OnDisconnecting event on my TRtcHttpServer to handle a client disconnection with session like this:

Code:

  if Sender is TRtcDataServer then
    with TRtcDataServer(Sender) do
      if Session <> nil then

All work fine if the client close the application...but if the client force the disconnection by calling the HttpClient.Disconnect method, on server the Session is always "nil".

[D.Tkalcec (RTC)]

Sessions have nothing to do with physical connections. Sessions should either use timeouts to expire automatically (which they do by default), or be closed manually by the Server when a Client sends a request to close its Session, providing the Session ID. If you are closing a Session every time the Client closes a connection, why use Sessions? Just store Client information in the Connection object.

Best Regards,
Danijel Tkalcec

[ISIGest]

This is true...the best way to do this is using the Info property of TRtcConnection?

[D.Tkalcec (RTC)]

Yes. If you want to store connection-related information, you can use the Info property on the TRtcConnection component. Just keep in mind that a physical connection does not always represent a single Client. When Clients are behind a Proxy, the same connection can be shared by multiple Clients. The same way, when working through a Proxy, a single Client can be using multiple different physical connections to communicate with the Server. It is entirely up to a Proxy to decide which physical connection will be used by which Client when a request has to be sent to a Server.

PS. Mobile internet connection providers usually have a Proxy for handling HTTP(S) requests.

Best Regards,
Danijel Tkalcec

[ISIGest]

Mmmm...this is a very big problem for me.
I need to store some unique information about the client and handle all comunication (Function calls,...) with this information. How can I bypass this.
Practically, I need a single client to have 2 unique connection (1 to direct comunication from client and another connection for callback)

[D.Tkalcec (RTC)]

RTC Messenger Client and Server demos do exactly this. One connection is used for sending data using remote function calls, the other connection is used for polling the Server for messages. Sessions are used to store Client information. If you need an example, take a look there.

Best Regards,
Danijel Tkalcec

[ISIGest]

Yes I see it.
I've moved all client info in a TList<> object and hanble all clients by ClientID passed by a function call param.

I've only a problem to check if a client is really connectd.
To check this "before" I use the OnDisconnect event in RtcHTTPServer, this event obviously has a single Sender : TRtcConnection param.
If I store no client information in Connection, how can I check if the client has lost connection?

[D.Tkalcec (RTC)]

You can store anything you want in the Connection object.

If you want to directly link a Client to its physical connections (instead of using Sessions with a timeout as in the RTC Messenger Demo), you can store Client's ID in Connection objects and keep track of each connections status (connected/ sending/ receiving/ disconnected) in your TList. When a Client closes one of its connections, you can use the ID stored in the Connection object to update the status of this connection in your TList and log the Client out if both connections are closed.

Best Regards,
Danijel Tkalcec

[ISIGest]

Sorry me, but if the physical connection is shared by two or more client (Just keep in mind that a physical connection does not always represent a single Client.), if I store client information in TRtcConnection.Info this infos are shared between the client that use this physical connection?

[D.Tkalcec (RTC)]

That is correct. And this is one of the reasons why I would NOT recommend logging out a Client when a physical connection closes. RTC Messenger Client and Server Demos use Sessions with a timeout to log out Clients after a period of inactivity. RTC Portal and the new Gateway have a similar mechanism, all based on timeouts and Client inactivity and NOT on the status of physical connections. If you want your Server to work correctly with Clients behind a HTTP proxy, do NOT bother with the status of a physical connection. Also keep in mind that some Clients might use HTTP/1.0 instead of HTTP/1.1, in which case a physical connection will be opened for every request and closed after every response.

Best Regards,
Danijel Tkalcec