Ideas to simulate a multithreaded sockets server

[Björnke von Gierke]

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"