Hi Bernard, I visited the page about the mechanism you pointed, but in that case it has an Apache/PHP server that handles multiple concurrent connections but it ends up passing the request to a Rev application using Sockets that will cause the same queuing on message processing. In fact, the requests to the server are multithreaded but the processing is not, as I could understand. Did I understand it right?
Regards, Marcio Alexandroni www.cialogica.com.br ( (11) 9989-8316 marcioalexandroni -- > From: Bernard Devlin <[email protected]> > Reply-To: How to use Revolution <[email protected]> > Date: Sat, 27 Feb 2010 09:43:17 +0000 > To: How to use Revolution <[email protected]> > Subject: Re: Ideas to simulate a multithreaded sockets server > > On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni > <[email protected]> wrote: >> The applications runs pure TCP/IP with a custom protocol to exchange data >> and it handles dozens of simultaneous calls at the same time, this is why it >> must be multithreaded, the queuing will not work in this case because of the >> time it would need to respond to the last caller. > > Hello Marcio, your fellow Brazilian is one of the experts on rev-built > http servers, so I'm sure he'll answer your question in detail soon. > > However, whilst he's sleeping, let me just point you to this > mechanism: http://www2.sahores-conseil.com/insead/index_en.html . > Pierre used that mechanism deployed (I believe) to the French Ministry > of Education, and it was a system used by students across France. > Since you need raw TCP/IP it doesn't sound like it will meet your > needs. > > Whilst Rev is not multi-threaded, can I just ask if you are using the > following format in your code: > > accept [datagram] connections on port number with message callbackMessage > > If so, then elsewhere in your code you may be able use the following > structure at places where you can accept potential interruptions: > > wait 10 milliseconds with messages > > When an existing connection's processing gets temporarily suspended by > the "wait", it means that a new connection can be accepted and > processing for that new connection can begin. > > These two together can provide a kind of message-passing concurrency. > For example, that is similar to the way that 'concurrent' processing > is done in Tcl (http://www.stanford.edu/~ouster/cgi-bin/papers/threads.pdf) > , > > Regards, > > Bernard > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
