Re: [twsocket] How to keep SslWSocket open in a multi-threaded console app?
Thanks Angus, in fact I likewise I have a simple switch at startup to
decide whether I'm running in GUI or service mode, which I share below
as a way of saying thanks to the 'list' as I did not take on-board the
fact that the Svcmgr::Application-CreateForm call means the TService
class is dervived from TObject item and that can have a TSslWSocket
component on it without any manual message pumps (rather than creating a
thread that then creates the SslWSocket):
//---
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
if(FindCmdLineSwitch(GUI))
{
Forms::Application-Initialize();
Forms::Application-CreateForm(__classid(TfrmMain), frmMain);
//(TfrmMain::OnShow then creates the TService based object
Forms::Application-Run();
}
else
{
if((!Svcmgr::Application-DelayInitialize) ||
(Svcmgr::Application-Installing()))
{
Svcmgr::Application-Initialize();
}
Svcmgr::Application-CreateForm(__classid(some class dervived from
TService), pService);
Svcmgr::Application-Run();
}
}
Thanks to all
--
Regards
Paul Read
Partner
Follow us: @nSolve http://www.twitter.com/nSolve
*nSolve Ltd*
33-35 Daws Lane
London NW7 4SD
England
www.nsolve.com http://www.nsolve.com
Tel: +44 (0) 1993 40 20 11
Tel(US): +1 617 273 2304
On 29/07/2015 08:15, Angus Robertson - Magenta Systems Ltd wrote:
Should I be calling MessageLoop or ProcessMessages?
Neither, Delphi windows services are message driven just like Windows
applications.
Most of my windows services are actually dual GUI/service, with a simple GUI
that
does not require any interaction when run as a service. This makes testing
vastly
easier, since the program can be run under the Delphi debugger and then
installed as
a Windows service once it's working.
Originally I wrote a simple service starter application that runs a standard
Windows
application as a service (with a command argument) and waits for it to finish
before
stopping, and sends a message if told to stop. I still sell an application
using
this technique after 18 years.
The second generation used the SvCom environment from:
http://www.aldynsoftware.com/
which creates a single application that can be run as a service or GUI, just
drop
components on a form, jkust works, but it's commercial.
For new applications I use DD Service Application Framework written by one of
the
ICS developers, but his web site seems to be down at the moment. I think it's
on
Code Central but search is useless and brings up thousands of results.
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] How to keep SslWSocket open in a multi-threaded console app?
Should I be calling MessageLoop or ProcessMessages? I now have a working (but horrible) solution: TService creates a thread to perform the main processing On the first event this thread creates a TSslWSocket (with MultiThreaded=false) and calls Connect At this point I must call *MessageLoop *(not ProcessMessages) to make the connection I then send some data At this point I must call *ProcessMessages *(not MessageLoop) to send the data After sending of the data I call WSocket-PostQuitMessage() so ProcessMessages exits and the thread can complete its event Thereafter on further events I then send some data At this point I must call ProcessMessages (not MessageLoop) to send the data After sending of the data I call WSocket-PostQuitMessage() so the thread can complete its work Note MessageLoop needed after Connect called, yet ProcessMessages needed after Send Works. But surely can't be right?? -- Regards Paul Read Partner Follow us: @nSolve http://www.twitter.com/nSolve *nSolve Ltd* 33-35 Daws Lane London NW7 4SD England www.nsolve.com http://www.nsolve.com Tel: +44 (0) 1993 40 20 11 Tel(US): +1 617 273 2304 On 28/07/2015 19:42, Paul Read - nSolve Ltd wrote: A MS-Windows service I'm doing the data send in the main thread of the service (there are no other threads) If I don't call the WSocket-PostQuitMesage then the MessageLoop runs for ever stopping my thread doing anything else. (If I don't call WSocket-MessageLoop nothing happens at all) -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] How to keep SslWSocket open in a multi-threaded console app?
A MS-Windows service I'm doing the data send in the main thread of the service (there are no other threads) If I don't call the WSocket-PostQuitMesage then the MessageLoop runs for ever stopping my thread doing anything else. (If I don't call WSocket-MessageLoop nothing happens at all) -- Regards Paul Read Partner Follow us: @nSolve http://www.twitter.com/nSolve *nSolve Ltd* 33-35 Daws Lane London NW7 4SD England www.nsolve.com http://www.nsolve.com Tel: +44 (0) 1993 40 20 11 Tel(US): +1 617 273 2304 On 28/07/2015 19:31, Angus Robertson - Magenta Systems Ltd wrote: Do you recommend this procedure for a MS-Windows service? It seems a bit of a strange concept to me Are you writing a console application or a service? Threads are generally unnecessary for ICS, except for some blocking functions like ping or SQL and when using hundreds of sockets in the same application. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] default gzip of json by THTTPServer - is it possible or am I to do it myself?
Angus co
I have enabled content encoding on my THTTPServer:
SizeCompressMin = 5000;
SizeCompressMax = 500;
Options = Options hoContentEncoding;
And return content to my client using AnswerString
String sResponseHeader =
pClientCnx-Version +
\r\nPragma: no-cache\r\n
Expires: -1\r\n
Access-Control-Allow-Origin: + sReferer + \r\n;
pClientCnx-AnswerString(Flags,
200 OK,
application/json,
sResponseHeader,
sResponseBody);
However if my client includes Accept-Encoding: gzip in its request
header the OnHttpContentEncode event is not called.
Looking in the source I see:
{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *}
function THttpConnection.CheckContentEncoding(const ContType : String):
boolean; { V7.21 are we allowed to compress content }
begin
Result := False;
if NOT (hoContentEncoding in FServer.Options) then exit; { V7.20
are we allowed to compress content }
if (ContType = '') or (Pos ('text/', ContType) 0) or (Pos ('xml',
ContType) 0) then begin{ only compress textual stuff }
if (FDocStream.Size FServer.SizeCompressMin) then exit; {
too small a waste of time }
if (FDocStream.Size FServer.SizeCompressMax) then exit; {
too large will block server and use a lot of memory }
Result := True;
end;
end;
What is the recommended way to correctly return gzip json content? Or is
it intended I should be performing the gzip logic before calling
AnswerString?
--
Regards
Paul Read
Partner
Find us on Facebook: http://www.facebook.com/nSolve
nSolve Ltd
33-35 Daws Lane
London NW7 4SD
England
www.nsolve.com
www.ntasktic.com
Tel: +44 (0) 1993 40 20 11
Tel(US): +1 617 273 2304
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
