Ideas to simulate a multithreaded sockets server

Sat Feb 27 12:00:58 EST 2010

Hi Bjoernke,

As I could understand, even using "accept with message", "read with
message", the processing will not be concurrent but queued. If there are 3
connections, it will accept ConnA and queue, ConnB and queue, ConnC and
queue, then will process the queue in line. If I have some reads in depth,
it will be queueing the messages generated after the read.

Did I understood it right?

Thinkig about on-rev and to be able to deploy it, thinkig about RevServer, I
could reimplement my communication protocol over HTTP, with full
multithreading and concurrent support from the Apache and the RevServer
message processing, then I could be handling the messaging system like I do
today, all requests processed immediately.

Thanks for your ideas.

Regards,

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

> From: Björnke von Gierke <bvg at mac.com>
> Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
> Date: Sat, 27 Feb 2010 17:04:05 +0100
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Subject: Re: Ideas to simulate a multithreaded sockets server
> 
> Hi
> 
> Yes, opening your own sockets is not possible with on-rev.
> 
> If you're not using on-rev:
> 
> Using "accept ... with message" is the first (and most important) step to get
> rev handle several connections concurrently. the second step is to always use
> read/write "with message", because otherwise it'd be blocking. Note that
> there's nothing in Rev that will make "with message" not work, but there's
> several traps that you can step into, which will make it not work. Maybe the
> "wait" command can produce problems, but I almost never use wait, and haven't
> tested it much. 
> 
> If you have computational heavy tasks to do for every connection (several
> seconds for each), then you can't do it with a single rev installation. A way
> around that is to launch command line versions of rev (using the 3.5 cgi
> engine as command line app), and do calculations there. The command line app
> then connects to your server and gives back the result that way. This will
> introduce various other kinds if latencies, and is hugely complex to implement
> (basically adds another server to code and manage). If you're below that
> limit, "send message in time" is a very important tool to divide larger tasks
> up so that they do not block your server.
> 
> If you have large files for each connection (large datasets to transfer, then
> you need chunking and bandwidth controlling. Chunking means to divide the one
> big file into several pieces, and send those after each other. This is needed
> because as long as a script is running, other scripts are blocked, so a single
> large file transfer will block your server for a too long time. Bandwidth
> control means to reduce the speed at which you do things, so as to not send
> too many data at once, which gives the server breathing room for accepting
> other tasks.
> 
> Things that won't work:
> 
> "Giving" a connection to another instance of rev: You said you'd like to
> distribute the workload that way. However, the _connection_ is always bound to
> whomever has accepted the socket communication, and there are security rules
> forbidding giving away a socket.
> 
> Not using send in time in the read/write to socket commands: Every such
> command will wait and block the _whole_ app until it is done. With network
> latency, this will be a problem for a very busy server (example: chatrev, with
> it's usually 5-6 chatters and less then a message per second does use blocking
> read/writes on the server, and never had a problem with that, not even when
> there where 25 chatters (max amount ever on chatrev)).
> 
> On-Rev: This runs within apache, and can only accept http traffic. no custom
> socket, no custom protocols (unless on top of http).
> 
> CGI only work with some caveats: cgi's normally run within apache, and can
> only accept http traffic. However they can use custom sockets, and they can be
> used as command line app without apache, where they are more similar to a
> normal standalone sans gui.
> 
> High traffic or high bandwidth servers: you will run into high end boundaries,
> with several connections per millisecond, and with big bandwidth demands. I
> have never reached these boundaries, and as long as you're not Word of
> Warcraft, or Google, you won't either.
> 
> Bjoernke
> 
> On 27 Feb 2010, at 15:11, Marcio Alexandroni wrote:
> 
>> Hi Bernard,
>> 
>> Pierre has posted here RevServer may support all the features I need in
>> full. In fact I have moved to the on-rev hosting, so I'll start testing the
>> connection from the PDAs using Sockets from my applications, I think I can
>> rewrite the protocol to use HTTP.
>> 
>> I tried your suggestion on "wait with messages" but it causes problems in
>> the message processing, I couldn't find the exact reason, but as the message
>> handler deals with databases and deals with encrypted packages, I think
>> something was not handled quite well when two clients connect at the same
>> time.
>> 
>> 
>>> From: Bernard Devlin <bdrunrev at gmail.com>
>>> 
>>> On Sat, Feb 27, 2010 at 11:17 AM, Marcio Alexandroni
>>> <marcio at cialogica.com.br> wrote:
>>>> I've been reading about Rev and CGI, but I read on rev Forums that the
>>>> necessary standalone engine necessary for the cgi-bin support is available
>>>> only on Rev <= 3.5, the new versions do not have the standalone engine
>>>> anymore. Do you know if it's true?
>>>> 
>>> 
>>> Yes this is true.  It is a great pity and I do not find the reasons
>>> for this move entirely convincing. If you are a licensed user, it
>>> might be possible to get the 3.5 engine from Runrev (actually, I think
>>> you just need the RevStudio 3.5 for your platform,and I think the
>>> standalone engine is bundled comes in there).
>>> 
>>> There is supposed to be a rev-server released.  I had thought it was
>>> going to be an apache module to get beyond the problem of any delays
>>> with a fork from CGI.  However, no information has been forthcoming,
>>> and it seems no one outside RunRev knows what was offered and what
>>> will actually be delivered, or when.
>>> 
>>> I seem to remember that within on-rev it is not possible to open
>>> sockets.  I think there was a talk at the Rev2009 conference by BvG
>>> who developed the Rev chat server.  I am not so interested in on-rev,
>>> so I didn't pay that much attention, but I thought he said that
>>> sockets could not be opened with on-rev, and that was the reason why
>>> he switch to a HTTP based protocol.  I'm sure someone else will
>>> comment on this soon if I'm mistaken.
>>> 
>>> BTW you still did not mention if you are using sockets and "with
>>> message".  Unless there is some reason why that will not work, your
>>> concerns about threading may prove unnecessary.
>>> 
>>> Bernard
> 
> -- 
> 
> official ChatRev page:
> http://bjoernke.com?target=chatrev
> 
> Chat with other RunRev developers:
> go stack URL "http://bjoernke.com/chatrev/chatrev1.3b3.rev"
> 
> _______________________________________________
> 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