Re: [twsocket] [QUESTION] ThttpServer and threading design
Francois Piette a écrit : > > That's what I do with my MidWare threaded TServerObject. You can apply the > same logic to the > HttpServer component. > > I have a class which manage a pool of threads. When a request comes in, I get > a thread from the > pool, adding a new one if necessary. The thread receive a reference to the > socket component , this > is important. The thread execute the lengthy database request and build the > response message and > pass it to the main thread for sending it back to the client. > > When the socket detect a session close, then it nullify the reference the > thread has so that the > thread know it has to throw away any data or pass it back to the main thread. that's what i'll almost implement. BTW, i think that, if the ICS Wiki project is realized, there should be a category that should present some design pattern to use with ICS components. May be i could help to write some of those articles :) Even, to explain the design patterns that are used internally by ICS :) Thanks for your help, Regards, -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
> back data to wrong client. That is why I know use an incremental > SessionID counter that I pass to worker to be sure to never send data > back to wrong socket and be sure to always get unique ID among > thousand of connections. That's good. You can use the reference to find out if it is still in the clients list and if yes, check the unique ID to see if it is still the same (a component may be freed and the exact same address allocated to a new one. This one will of course have a new ID). -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: "Dod" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Thursday, February 09, 2006 2:37 PM Subject: Re: [twsocket] [QUESTION] ThttpServer and threading design > Hello Francois, > > Exactly what I do now, but what reference do you pass to thread ? At > beginning I did it with socket.handle (if I remember well by it was > long time ago) by I noticed that if during work job the socket is > closed and a new connexion come, then it could happend that this new > socket get same handle as previous closed one so my worker may sent > back data to wrong client. That is why I know use an incremental > SessionID counter that I pass to worker to be sure to never send data > back to wrong socket and be sure to always get unique ID among > thousand of connections. > > FP> That's what I do with my MidWare threaded TServerObject. You can apply > the same logic to the > FP> HttpServer component. > > FP> I have a class which manage a pool of threads. When a request comes in, I > get a thread from the > FP> pool, adding a new one if necessary. The thread receive a reference to > the socket component , this > FP> is important. The thread execute the lengthy database request and build > the response message and > FP> pass it to the main thread for sending it back to the client. > > FP> When the socket detect a session close, then it nullify the reference the > thread has so that the > FP> thread know it has to throw away any data or pass it back to the main > thread. > > FP> -- > FP> Contribute to the SSL Effort. Visit > FP> http://www.overbyte.be/eng/ssl.html > FP> -- > FP> [EMAIL PROTECTED] > FP> Author of ICS (Internet Component Suite, freeware) > FP> Author of MidWare (Multi-tier framework, freeware) > FP> http://www.overbyte.be > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Hello Francois, Exactly what I do now, but what reference do you pass to thread ? At beginning I did it with socket.handle (if I remember well by it was long time ago) by I noticed that if during work job the socket is closed and a new connexion come, then it could happend that this new socket get same handle as previous closed one so my worker may sent back data to wrong client. That is why I know use an incremental SessionID counter that I pass to worker to be sure to never send data back to wrong socket and be sure to always get unique ID among thousand of connections. FP> That's what I do with my MidWare threaded TServerObject. You can apply the same logic to the FP> HttpServer component. FP> I have a class which manage a pool of threads. When a request comes in, I get a thread from the FP> pool, adding a new one if necessary. The thread receive a reference to the socket component , this FP> is important. The thread execute the lengthy database request and build the response message and FP> pass it to the main thread for sending it back to the client. FP> When the socket detect a session close, then it nullify the reference the thread has so that the FP> thread know it has to throw away any data or pass it back to the main thread. FP> -- FP> Contribute to the SSL Effort. Visit FP> http://www.overbyte.be/eng/ssl.html FP> -- FP> [EMAIL PROTECTED] FP> Author of ICS (Internet Component Suite, freeware) FP> Author of MidWare (Multi-tier framework, freeware) FP> http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
> What you're doing is transfering a socket from main thread > context to your work thread context. > My purpose is not the following. What i mean is executing > all the SQL stuff within the thread, > and the connection stuff within the main thread. That's what I do with my MidWare threaded TServerObject. You can apply the same logic to the HttpServer component. I have a class which manage a pool of threads. When a request comes in, I get a thread from the pool, adding a new one if necessary. The thread receive a reference to the socket component , this is important. The thread execute the lengthy database request and build the response message and pass it to the main thread for sending it back to the client. When the socket detect a session close, then it nullify the reference the thread has so that the thread know it has to throw away any data or pass it back to the main thread. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Dod a écrit : > Ok so you do nearly same as me. But at the end of threaded job I > verify the client still exists before sending result. > > When a session connect I set a SessionID incremental counter in > MySocketClient class because I noticed that same socket handle can be > re-used by a next connection. > > So when I finish the job I just check if SessionID is still part of > actual session's list. > > But setting a 'killed' value in working thread is also good. > Yes. In fact, the more i work on the overall design, the more it looks like midware's one :) Except that i can't use midware ! Damn ! Thanks for your help ! Best regards, -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Hello Guillaume, Ok so you do nearly same as me. But at the end of threaded job I verify the client still exists before sending result. When a session connect I set a SessionID incremental counter in MySocketClient class because I noticed that same socket handle can be re-used by a next connection. So when I finish the job I just check if SessionID is still part of actual session's list. But setting a 'killed' value in working thread is also good. GM> Dod a écrit : >> Hello Guillaume, >> >> Until know what I use to do is to create a worker thread and send jobs >> (with pointer to socket client object) and then worker send back a >> message to socket thread with pointer of data to send back to client. >> So all socket things is done from same thread. >> Dettaching clientsocket from socket thread to attach it into worker >> thread when starting lenghty operation is something I never did. GM> What you're doing is transfering a socket from main thread context to your work thread context. GM> My purpose is not the following. What i mean is executing all the SQL stuff within the thread, GM> and the connection stuff within the main thread. When i meant "attaching the socket" it was not using the MultiThread GM> property or the De/AttachThread methods. i just meant attach the socket reference in order to be used in the OnThreadTerminate GM> event (which is in the main thread). >> I have one question regarding this... if some socket event come during >> the lengthly operation (OnDisconnect or OnDataAvailable for example), >> will they be triggered during operation or only at end of it ? >> If socket is MultiThread:=true it should use its own message queue so >> react instantly whenever the thread it is attached into is busy isn't >> it ? GM> if my purpose was to use socket within a thread context, this should be, yes, a constraint to take into account. GM> The design i provided in the first mail is meant precisely not to bother with such constraints. GM> From Bjornar suggestion, if the client connection is closed, then all that has to be done is to stop/terminate the worker GM> thread if active. GM> Regards, GM> -- GM> Guillaume MAISON - [EMAIL PROTECTED] GM> 83, Cours Victor Hugo GM> 47000 AGEN GM> Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 GM> e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Dod a écrit : > Hello Guillaume, > > Until know what I use to do is to create a worker thread and send jobs > (with pointer to socket client object) and then worker send back a > message to socket thread with pointer of data to send back to client. > So all socket things is done from same thread. > Dettaching clientsocket from socket thread to attach it into worker > thread when starting lenghty operation is something I never did. What you're doing is transfering a socket from main thread context to your work thread context. My purpose is not the following. What i mean is executing all the SQL stuff within the thread, and the connection stuff within the main thread. When i meant "attaching the socket" it was not using the MultiThread property or the De/AttachThread methods. i just meant attach the socket reference in order to be used in the OnThreadTerminate event (which is in the main thread). > I have one question regarding this... if some socket event come during > the lengthly operation (OnDisconnect or OnDataAvailable for example), > will they be triggered during operation or only at end of it ? > If socket is MultiThread:=true it should use its own message queue so > react instantly whenever the thread it is attached into is busy isn't > it ? if my purpose was to use socket within a thread context, this should be, yes, a constraint to take into account. The design i provided in the first mail is meant precisely not to bother with such constraints. From Bjornar suggestion, if the client connection is closed, then all that has to be done is to stop/terminate the worker thread if active. Regards, -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Hello Guillaume, Until know what I use to do is to create a worker thread and send jobs (with pointer to socket client object) and then worker send back a message to socket thread with pointer of data to send back to client. So all socket things is done from same thread. Dettaching clientsocket from socket thread to attach it into worker thread when starting lenghty operation is something I never did. I have one question regarding this... if some socket event come during the lengthly operation (OnDisconnect or OnDataAvailable for example), will they be triggered during operation or only at end of it ? If socket is MultiThread:=true it should use its own message queue so react instantly whenever the thread it is attached into is busy isn't it ? GM> Bjørnar Nielsen a écrit : >> I have a similar design, but I also have a pointer to the thread in the >> THttpConnection so that the connection can set a flag on the thread if the >> connection is dropped before the thread has finished the work and risk using >> a freed connection. GM> True ! i haven't seen it ! >> This design could serve several connections/threads at the same time. GM> Thanks a lot ! GM> -- GM> Guillaume MAISON - [EMAIL PROTECTED] GM> 83, Cours Victor Hugo GM> 47000 AGEN GM> Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 GM> e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
Bjørnar Nielsen a écrit : > I have a similar design, but I also have a pointer to the thread in the > THttpConnection so that the connection can set a flag on the thread if the > connection is dropped before the thread has finished the work and risk using > a freed connection. True ! i haven't seen it ! > This design could serve several connections/threads at the same time. Thanks a lot ! -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] [QUESTION] ThttpServer and threading design
I have a similar design, but I also have a pointer to the thread in the THttpConnection so that the connection can set a flag on the thread if the connection is dropped before the thread has finished the work and risk using a freed connection. This design could serve several connections/threads at the same time. Regards Bjørnar > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume MAISON > Sent: 9. februar 2006 10:59 > To: ICS support mailing > Subject: [twsocket] [QUESTION] ThttpServer and threading design > > Hi everyone, > > i've an application to write, a client and a server. > i've choosen to use the HTTP protocol to enable communication > through them. > Hence, i'll use the THttpServer as my server front-end. > > my question is the following : > some requests may use some database stuff (SQLite). It > shouldn't be the case, but, in case the SQL stuff may need > long duration (long>10 secs) i prefer to use threads to get > DB data, as there may be several clients connecting at the same time. > > Am i right to implement such requests as this : > Form.OnGetDocument : > Create a Thread with the HttpConnection attached and > FreeOnTerminate:=True; > Assign a OnThreadTerminate > Run the thread > Set Flags to hgWillSendMySelf > > Form.OnThreadTerminate > AttachedHttpConnection.AnswerString/AnswerStream/AnswerWhatever > > Does this design seem good ? > i mean will i be able to serve several connections at the > same time (independantly of DB concurrential access that i'll > manage within thread context) ? > > Thanks in advance for your help ! > > Regards, > > > -- > > Guillaume MAISON - [EMAIL PROTECTED] > 83, Cours Victor Hugo > 47000 AGEN > Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : > [EMAIL PROTECTED] - Web : http://nauteus.com > > -- > To unsubscribe or change your settings for TWSocket mailing > list please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
