Ideas to simulate a multithreaded sockets server

[Marcio Alexandroni]

Hello Andre,

Thank you for your ideas. It's good to know there are more Brazilians
here... 

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.

Anyway, can you explain a little bit more about the CGI idea and the
portable server? 

Thank you.

PS: moro em Bragança Paulista/SP. Assisti a um video seu, acho que foi da
conferência 08. Abraço.

Marcio Alexandroni
www.cialogica.com.br
 ( (11) 9989-8316
  marcioalexandroni
-- 



> From: Andre Garzia <andre at andregarzia.com>
> Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
> Date: Fri, 26 Feb 2010 15:15:39 -0300
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Subject: Re: Ideas to simulate a multithreaded sockets server
> 
> Oi Marcio,
> 
> I think you're now officially the second Brazilian using Revolution. Right
> now Rev is single threaded and that is all. What you could build is a pool
> of Rev processes coordinated by a master process. So you could have a Linux
> standalone launch multiple socket servers and then play the role of proxy
> relaying the connection to them. This would involve changing your protocol
> since we can't really delegate a connection to another process, you'd need
> to reply to the client with something like: "hey connect again on port
> something" and it would reconnect using one of the socket servers.
> 
> I don't know your application logic, but if your socket server acts fast
> enough then some queueing is not that bad.
> 
> In the meanwhile, if you're doing your logic on top of HTTP, why not use a
> simple portable server and Rev based CGI, this would solve the problem (and
> propose new ones as you'd need to handle the statelessness)
> 
> Cheers
> andre
> PS: Você é de sampa né?
> 
> On Fri, Feb 26, 2010 at 2:44 PM, Marcio Alexandroni <marcio at cialogica.com.br
>> wrote:
> 
>> Hi,
>> 
>> I'm currently building a new version of a product that has 3 modules:
>> 
>> * A sockets server that operates the application logic.
>> * The administration module which communicates with the server using
>> sockets
>> to set properties.
>> * The PDA module that is actually what users interact and that also
>> communicates with the server using sockets.
>> 
>> Today I have the server and administration modules written in Delphi and
>> Palm/WinMo solutions on the PDAs.
>> 
>> It would be very, very interesting if I could have a server that I could
>> deploy on Windows, Linux or Mac machines, so I built a "test" version in
>> Rev, but I found it does not handle multiple requests, but queues and
>> process one at a time, which is not suitable for this solution.
>> 
>> I've been thinking if there is any way to overcome this situation, perhaps
>> launching a separate process for each connection, passing the client
>> address
>> to this new process, this way I could return immediately from the handler,
>> letting it process the queue, while the process actually handles the
>> request
>> and feedback to the client.
>> 
>> Does anyone have any idea if starting multiple Rev subprocesses is possible
>> or perhaps any other idea on how to do this concurrent handling in Rev?
>> 
>> Thanks in advance.
>> 
>> Marcio Alexandroni
>>  ( (+55 11) 9989-8316
>> Brazil
>> Skype: marcioalexandroni
>> --
>> 
>> 
>> _______________________________________________
>> 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
>> 
> 
> 
> 
> -- 
> http://www.andregarzia.com All We Do Is Code.
> _______________________________________________
> 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