RTC Forums
May 05, 2024, 03:16:48 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Disconnect when "Post"  (Read 5556 times)
YuraZ
Newbie
*
Posts: 39


« on: October 05, 2012, 12:29:12 PM »

Hello!

I'm using TRtcHttpServer on Server-side and TRtcHttpClient on Client-side (Server app and Client app are executing on different computers in LAN). And I'm trying to detect disconnect on client from server when on client executing TRtcClientModule.Post (Server is not sending answer 10 seconds for delay on client) and I turn off ethernet-cable from client computer. But events (e.g. OnConnectLost, OnConnectFail, OnConnectError, OnDisconnect) are not executing. How i can to detect this disconnect failure?

Thanks a lot.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: October 05, 2012, 01:56:57 PM »

When using remote functions in event-driven mode (with the RtcClientModule.Post method), implement the RequestAborted events on RtcResult components to get notified about remote calls which have been aborted because of communication problems (disconnects during communication or inabbility to connect). This gives you precise control over each specific remote function call.

For general notifications about communication problems (independent of the actual remote function call being made), use the OnRepostCheck or OnResposeAbort events on the RtcClientModule (for remote function calls being made through a specific RtcClientModule) or RtcHttpClient component (for any kind of communication made through a specific connection component).

Please note that these events will ONLY be triggered if your components are actually trying to send or receive data. They won't get triggered if you are not making any remote function calls, but will be called if you make a remote function call after a connection was closed.

To specify how long you are willing to wait before you want the operating system API to stop trying to recover a broken connection (TCP/IP has mechanisms to recover from some connection problems automatically and some operating system APIs have a very high tollerance for connection errors, sometimes even trying to recover a connection which has been broken for several minutes), use the TimeoutsOfAPI and Timeout properties on the RtcHttpClient component.

It is also a good idea to specify a positive value for the AutoRepost property (how often you want a request to be re-posted before the OnRepostCheck/OnResponseAbort events get triggered) on the RtcClientModule component, which would take care of short temporary connection problems. Also make sure to set the ReconnectOn properties on the RtcHttpClient component, so a connection will be automatically re-opened in case of a connect error, failure or loss. By setting the AutoConnect property on the RtcHttpClient component to TRUE (in addition to setting ReconnectOn properties), you also don't have to manually call Connect, but can leave the task of opening and closing connections to the RtcHttpClient component (as needed).

IMPORTANT NOTE: You can NOT rely on Disconnect events between the actual communication tasks, because most operating system APIs handle connection opening and closing by themselves, or don't notify the Application about connection problems until data has to be actually sent or received. This goes for all blocking APIs. The only API which would notify you about a physical connection loss even if the components are idle, is the async WinSock API, which is used only on Windows and only when the Blocking, useProxy and useWinHTTP properties on the RtcHttpClient components are set to FALSE. But even there, the API could decide to wait reporting a broken connetion and try to repair a connection in case data has to be sent. If waiting for data but not actively sending anything (for example, after a complete request has already been sent), it will depend on your TimeoutsOfAPI and Timeout properties how long it would take for a physical disconnect (for example, when you pull the network cable out) to be seen as a problem and be reported as such.

Best Regards,
Danijel Tkalcec
Logged
YuraZ
Newbie
*
Posts: 39


« Reply #2 on: October 08, 2012, 07:21:50 AM »

Thanks a lot, Danijel!
Logged
YuraZ
Newbie
*
Posts: 39


« Reply #3 on: October 08, 2012, 09:45:27 AM »

Danijel, thanks for the previous answer, but i have more questions.

Client program is always waiting data from Server in parallel threads (one client program has many connections to server) by this code:
Code:
self.f_connection_module.Data.NewFunction(CF_WAIT);
self.f_connection_module.Call(f_cr_wait);

I used your advice to implement events such as OnRepostCheck, OnResponseAbort, RequestAbort. But when i turn off ethernet cable from client these events are not triggered. Only OnConnectLost and OnDisconnect are triggered 10-15 seconds later. Here is code:
Code:
procedure RtcHttpClient1ConnectLost(Sender: TRtcConnection);
begin
  f_connection_module.SkipRequests;
  f_connection.DisconnectNow(true);
end;

But << self.f_connection_module.Call(f_cr_wait) >> is not ending.
How i can force ending to this Call?

Thanks a lot, Danijel, and sorry for my English.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #4 on: October 08, 2012, 10:12:40 AM »

OnRepostCheck, OnResponseAbort and RequestAborted events would be called if you didn't use the SkipRequests method. The SkipRequests method should ONLY be used when you are closing the Application and do NOT want to continue using the components. By calling the SkipRequests method, you are removing all the requests from the request queue silently, without triggering any events. And this is why all the other events related to these requests are NOT being called in your case.

Also, you should NEVER call the DisconnectNow method from inside ANY event triggered by any RTC connection component. That method may ONLY be called directly from the MAIN thread (also NOT from a synchronized event call). When you call it from any RTC event, because it is a blocking call, it will effectively block the component from doing what you are asking it to do. And, if you call DisconnectNow from the OnDisconnect event and the connection was not already closed, you would create an endless loop which would either freeze the Application (when calling the method synchronized) or freeze the thread from which DisconnectNow was called.

Best Regards,
Danijel Tkalcec
Logged
YuraZ
Newbie
*
Posts: 39


« Reply #5 on: October 08, 2012, 10:36:20 AM »

Thanks, Danijel.
I removed calling SkipRequests, but these methods are still not triggered.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #6 on: October 08, 2012, 12:40:15 PM »

Have you also removed DisconnectNow (read my post above)?

Best Regards,
Danijel Tkalcec
Logged
YuraZ
Newbie
*
Posts: 39


« Reply #7 on: October 08, 2012, 01:30:31 PM »

Yes, of course.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #8 on: October 08, 2012, 03:49:12 PM »

Without seing more of your code (or having a Client and a Server Project which I could test), I'm afraid I can't help you more than I already did. If you can't get it working, please create a new simple Client and Server example Project which demonstrate the issue, with a short explanation on how to reproduce it. The Project should only use standard Delphi components.

PS. I also need to know which Delphi version you are using to compile the Projects and which platforms you are compiling the Client and the Server for (Win32, Win64, Mac OSX or iOS).

Best Regards,
Danijel Tkalcec
Logged
YuraZ
Newbie
*
Posts: 39


« Reply #9 on: October 08, 2012, 03:50:47 PM »

Ok. Danijel. I understand you. I'll try to reproduce this.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.027 seconds with 18 queries.