Hi
Thanks for the example.
My application is a server using SSL encryption to transport a custom protocol,
where as your example is a "load-test client"
as far as I can tell.
However the idea of having multiple clients grouped together on a smaller
number of separate (server) threads would minimize
my resource consumption.
But as far as I understand Arno, he would recommend not going multithreaded
unless absolutely necessary
e.g. lengthy operation which blocks socket I/O.
Perhaps a combination of my previous code and a fixed number of server threads
in a "thread pool" could be applied.
When an incoming session is available I could switch between the available
server threads
e.g.
serverthread[index++]->handleRequest(...)
if( index >= MaxServerThreads )
{
Index = 0;
}
Best regards
Kurt
-----Oprindelig meddelelse-----
Fra: [email protected] [mailto:[email protected]] På vegne
af Fastream Technologies
Sendt: 1. september 2010 11:37
Til: ICS support mailing
Emne: Re: [twsocket] TSslWSocket in a non-blocking multithreaded server
Hello,
AFAIU, you are suggesting multiple-clients/thread design. We have a source
code example of that (C++) at,
http://www.fastream.com/webstresstester.php
HTH,
SZ
On Wed, Sep 1, 2010 at 12:30 PM, Arno Garrels <[email protected]> wrote:
> Kurt Andersen wrote:
>
> > I have now implemented a working multithreaded test (server)
> > application which uses both the TWSocket and the TSslWSocket in a
> > non-blocking manner.
>
> Just a side note to your design "One Thread Per TWSocket Instance",
> it's not optimal IMO. TWSocket objects allocate at least one shared,
> hidden window per thread which is waste of resources and decreases
> the maximum possible number of concurrent client connections.
> TWSocket actually works non-blocking it uses the non-blocking
> winsock API. What is blocking the socket I/O is lengthy tasks
> running in the same thread context.
>
> > I just have to be sure that I understood your reference to
> > f_ERR_remove_state(unsigned ThreadID).
> > Should I call this function just before the Thread's execute method
> > returns, sending the threads ThreadID as param ?
>
> Yes, it is a cleanup function.
>
> --
> Arno Garrels
> --
> 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
>
--
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
--
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
