TSQLite3HttpClientWinSock open channel on create

VojkoCendak · 2012-11-17 02:03:49

Hi,

why did you choose to open channel on create?

IMHO it's better to open it when we first call one method.

constructor TSQLite3HttpClientWinSock.Create(const aServer, aPort: AnsiString;
  aModel: TSQLModel);
begin
  inherited Create(aModel);
  fSocket := THttpClientSocket.Open(aServer,aPort); ===> WHY open here? why not when you first call it?
{$ifdef USETCPPREFIX}
  fSocket.TCPPrefix := 'magic';
{$endif}
  KeepAliveMS := 20000; // 20 seconds connection keep alive by default

and also you could build if there is network error (which IS normal) and each time user tries to execute it tries to reconnect.

Because THttpClientSocket.Open(aServer,aPort) is in contructor now, on error
the client gets destroyed, BUT we don't know

  aClient := TSQLite3HttpClientWinSock.Create(Host,IntToStr(Port),Model);
  except
    aClient:= nil;
    raise;
  end;

.... and code
  if aClient<>nil then ==> unnecessary, why? aClient should be always ready to work ;)
  ...

IMHO it's more clean:

aClient := TSQLite3HttpClientWinSock.Create(Host,IntToStr(Port),Model).
aClient.Services['Potopne_Svc'].Get(CN); ==> or at least here
try
 CN.MyMethod; ==> here you open the channel
except
  ...
end;

Last edited by VojkoCendak (2012-11-17 02:05:37)

VojkoCendak · 2012-12-02 01:09:50

maybe I'm missing something., (Delphi2009ent)

We try to use TCrtSocket.
It is said is faster that Indy and blcksock, but the use of latter are running ok in
case of network disruption.

1. Issue: I cannot call close (it's private), if I want to -> I need to recreate object.

2. serious issue

    FTcp.OpenBind(Host,IntToStr(Port),false);  // this one works ok , it says cannot open socket ....
    // this one is strange
    FTcp.Open(Host,IntToStr(Port)); // after we have access violation ????

How can this be?
We just try to call same FTCP.Open(...) over and over untill it really opens and why AV comes in ?

please note that we used succesfully blcksock in same scenario and in production.

3. Could OpenBind have shorter timeout delay (no need to be so long) ?

Last edited by VojkoCendak (2012-12-02 01:11:33)

ab · 2012-12-03 07:16:32

0. TWinHTTP class (the one using WinHTPP API) is perhaps a bit slower, but more reliable than TCrtSocket for HTTP process over a network, and is able to handle proxy and https if needed.

1. I'm doing some code refactoring in mORMotHttpClient.pas unit to easy re-connection in case of connection break.

2. Open is a constructor, so you have to call it FTCP := TCrtSocket.Open()

3. Change TCrtSocket.TImeOut value if default value of 10000 (i.e. 10s) is too big for you.

VojkoCendak · 2012-12-03 08:12:48

this is great. We're using already in production with success: easy, small and fast . Thank you for your great work.

- Is it possible to implement general retry mechanism on the level of interfaces,
so that it will always be ready to reconnect if possible not just do access violation.

Let's say: we use a lot in app:

  // this impl needs constant chekcing and recreating ===
  // initialization start
   FMySvc := nil;
   FClient:= TSQLite3HttpClientWinSock.Create(Host,IntToStr(Port),lmodel); // don't put connect method here, otherwise we have to
     // constantly recreate FClient. IMHO it's not needed. Open could be when first interface call is attempted.
   FClient.Services.Info(TypeInfo(IMySvc)).Get(FMySvc); // we just initialize at one point
   // this impl needs constant checingk and recreating ===

...
  // we want to use FMySvc interface all over application:
  FMySvc.MyMethod; // this statement should be able to ALWAYS try to reconnect in case of network failure
  // that way IMHO the client is rock solid

At current implementation we now have to have function where we always check whether the service
is available, or if something gets wrong, so that we are able to reconnect our selves.
1. This is messy
2. we can do it only one function for one service
3. we have to kill the client and recreate it again and again in case of failure

For example: I looked at the pipe client server sample and it didn't reconnect when the server was restarted in between.

Last edited by VojkoCendak (2012-12-03 08:26:54)

ab · 2012-12-03 13:10:40

I've introduced TSQLRestClientURI.InternalCheckOpen/InternalClose methods to properly handle remote connection and re-connection for all mORMot transmission protocols (including HTTP, GDI messages or named pipes).

You can try it and report any issue / enhancements.

See http://synopse.info/fossil/info/5f9e7fafce

VojkoCendak · 2012-12-03 22:16:23

superbe.

Where can I get these files ? Tried in downloads but there are no changes in there.

ab · 2012-12-04 05:30:00

See http://synopse.info/fossil/wiki?name=Get+the+source

mORMot Open Source

#1 2012-11-17 02:03:49

TSQLite3HttpClientWinSock open channel on create

#2 2012-12-02 01:09:50

Re: TSQLite3HttpClientWinSock open channel on create

#3 2012-12-03 07:16:32

Re: TSQLite3HttpClientWinSock open channel on create

#4 2012-12-03 08:12:48

Re: TSQLite3HttpClientWinSock open channel on create

#5 2012-12-03 13:10:40

Re: TSQLite3HttpClientWinSock open channel on create

#6 2012-12-03 22:16:23

Re: TSQLite3HttpClientWinSock open channel on create

#7 2012-12-04 05:30:00

Re: TSQLite3HttpClientWinSock open channel on create

Board footer