Ideas to simulate a multithreaded sockets server

[Pierre Sahores]

Hi Marcio,

Did you have an eye to the on-rev / irev technology. It's definitively  
the most usable way to go, from yet. Even if CGI and PHP/Rev Stacks  
went good underground ways to use, over the 15 past yahrs, the  
revServer witch will be made public and free available in the  
forecoming months by RunRev is a very stable et fast running engine  
from yet.

About your multi-threading need, i can't help, for yet, as long as we  
can't see how the revServer is / is'nt able for yet (it could be, at  
least with a adapted xinetd config under linux - i did so for metacard/ 
suse, yahrs ago) to handle multi-thread.

Instead of devlopping your own framework first, why would you not try  
to test your project design in using the on-rev platform ? I use it  
for my own (two projects up and running, the thirst is on desk) with  
great satisfaction.

Kind regards,

P.

Le 27 févr. 10 à 12:31, Marcio Alexandroni a écrit :

> 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 <bdrunrev at gmail.com>
>> Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
>> Date: Sat, 27 Feb 2010 09:43:17 +0000
>> To: How to use Revolution <use-revolution at lists.runrev.com>
>> Subject: Re: Ideas to simulate a multithreaded sockets server
>>
>> On Fri, Feb 26, 2010 at 6:28 PM, Marcio Alexandroni
>> <marcio at cialogica.com.br> 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
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.woooooooords.com
www.sahores-conseil.com