TWSocketThrdClient and THttpCli.Post in socket thread

[Dmytro Lendel 1]

Hello,

I need help if you please

We used socked server with our devices many years and it works nice. Protocol is ASCII and very simple.

Now we start to use thread socked server because we need to make same heavy queries sometimes depends on device`s request. Query is http request with get and post methods.

My question is following. Is it safety to call http request from TWSocketThrdClient onClientdata event? As far as I can see TWSocketThrdClient will create own thread inside Socked thread. Correct?

What is best way to implement this logic? Hope, somebody will help me

Thank you

Regards Dmytro

[Angus Robertson 574]

Beware that TWSocketThrdServer has not been updated or tested for over 10 years, and specifically not with the latest OpenSSL which changed the way thread locking works.  Nor does it have any of the many new features in TWSocketServer. 

 

You may be better off retaining TWSocketServer and only starting a thread if you expect a long query, which is how TFtpServer works, look at Client.ProcessingThread which is used for processor heavy functions.

 

Really do need to bring TWSocketThrdServer up to date, but very few people need it.

 

Angus

 

[Dmytro Lendel 1]

Hi,

Thank you so much!

[Dmytro Lendel 1]

Hi

OverbyteIcsThrdSrvV2 will be good example? Can I do like in OverbyteIcsThrdSrvV2?

 

  { TClientThread is our worker thread class. Each time a client connect, a }
  { new TClientThread is instanciated and client socket attached to it so   }
  { events are processed in the thread's context.                           }
  { Remember that multithreading requires synchronization, specially when   }
  { updating GUI or accessing shared data.                                  }
  { TClientThread uses OnDisplay event to display data on the application   }
  { main form. Synchronization is automatically done.                       }
  {$M+}       { Needed for Published to take effect }
  TClientThread = class(TThread)
  private
      FWSocket        : TWSocket;             { Reference to client socket  }
      FMsg            : String;               { Message to be displayed     }
      FOnDisplay      : TDisplayProc;         { Event variable              }
      FThreadAttached : Boolean;              { TRUE once socket attached   }
      FCritSect       : TRTLCriticalSection;
      procedure DisplayMsg;                   { Synchronized procedure      }
  public
      constructor Create(Suspended : Boolean);
      destructor  Destroy; override;
      procedure Execute; override;            { Main method                 }
      procedure Display(const Msg : String);  { Takes care of synchroniz.   }
  published
      property WSocket   :      TWSocket     read  FWSocket
                                             write FWSocket;
      property ThreadAttached : Boolean      read  FThreadAttached
                                             write FThreadAttached;
      property OnDisplay :      TDisplayProc read  FOnDisplay
                                             write FOnDisplay;
  end;

  { TThrdSrvClient is the class which will be instanciated by server        }
  { component for each new client. N simultaneous clients means N           }
  { TThrdSrvClient will be instanciated. Each being used to handle only a   }
  { single client.                                                          }
  { We can add any data that has to be private for each client, such as     }
  { receive buffer or any other data needed for processing.                 }
  TThrdSrvClient = class(TWSocketClient)
  protected
    procedure   WndProc(var MsgRec: TMessage); override;
    procedure   WMStartCnx(var Msg: TMessage); message WM_START_CNX;
  public
    ClientThread : TClientThread;
    RcvdLine     : String;
    ConnectTime  : TDateTime;
    procedure   StartConnection; override;
  end;

[Angus Robertson 574]

I've never looked at the OverbyteIcsThrdSrvV2 sample so can not comment on, I'd only say don't use a thread unless you really need it. 

 

Making HTTP requests with GET and POST are asynchronous so are not blocking your client unless you need many milliseconds of processor time to read through hundreds of megs of response.  Threads are sometimes needed for database access to process large query results, but my own database driven web server does not yet need threads for it's load, SQL queries usually only take 50ms or less. 

 

Angus

 

[Dmytro Lendel 1]

Ok. May be you are right. No reason to discovery the bike Thank you

[Angus Robertson 574]

In general, ICS servers will support a few hundred clients doing simple downloads or uploads, before threads are needed to use multiple CPUs.   That may change if ARM based server chips appear with dozens of lower spec cores than current Xeon chips with just a few cores (unless you pay silly money).  Only think about threads when it slows down. 

 

Angus

 

[FPiette 383]

11 hours ago, Dmytro Lendel said:

We used socked server with our devices many years and it works nice. Protocol is ASCII and very simple.

Now we start to use thread socked server because we need to make same heavy queries sometimes depends on device`s request. Query is http request with get and post methods.

HTTP component is asynchronous, it doesn't need a thread to be non blocking. It will consume very few CPU. As I see your application, you don't need multithreading at all. A thread would be necessary if - for example - you have a lengthy computation.