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 <[email protected]> > Reply-To: How to use Revolution <[email protected]> > Date: Sat, 27 Feb 2010 17:04:05 +0100 > To: How to use Revolution <[email protected]> > 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 <[email protected]> >>> >>> On Sat, Feb 27, 2010 at 11:17 AM, Marcio Alexandroni >>> <[email protected]> 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 > [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
