A timely question. :-) I have been looking at Web 2.0, node.js, jquery, and all the other javascript libraries coming out now. It seems to me, that the general strategy is to find a way to do non-blocking I/O, so that one of your html div's dos'nt
stall the whole page.
Of course, after playing around with a few Perl GUI libs, like Tk and Gtk2, you see the value of not having direct socket connection loops as your main loop. Instead, you run event-loop systems on both ends, both the socket and the server. The event-loops make and service the socket connections, so the sockets can be read or written to, in a non-blocking manner.
So, the whole idea of Web 2.0 is to break your monitor/screen into little divs( divisions), and each little div can run it's own javascript routine, automatically opening sockets and transferring information. So with event-loop based non-blocking I/O, many sockets can be simultaneously opened from your browser window, and be updating independently, without requiring an entire page refresh, you only need to refresh the div which originated the socket request.
The much heralded node.js is nothing more an eventloop system, written in javascript, which can handle JSON ( javascript object notation) packages of data.
Furthermore, javascript itself is the eventloop running your browser. If you turn off javascript, you only prevent external scripts from being run, but the basic browser eventloop continues to run.
So..... if I was designing a general purpose strategy, it would be to be eventloop based, on both the server and client, AND the client should be able to be integrated into a web browser, which should be easy enough with javascript. It needs to handle things like I/O Promises, which is the eventloop's way of saying the "information is being readied for delivery".
Those are my current thoughts. :-)
| [reply] |
Why do you think the client should be integrated into a browser?
I don't think I disagree with you, in today's day and age, EVERYTHING runs in a browser. But maybe there's a good reason to have a client that isn't browser integrated.
| [reply] |
I agree, I don't understand why there are not more custom clients out there. It seems everyone likes the standardization of the browser, and to be honest, with the HTML5 canvas element, it seems everything can be done... any custom widget can be made, running right in a browser. Plus, cell phones and smart phones have a built-in browser.
If I had a business that needed sockets, I would avoid the browser myself, except for putting a page out to the public. Internal parties, would avoid the filtering thru the various web servers, and open direct socket connections .... like a RealTime Chat with video between endpoints. See Tk encrypted echoing-chat client and server and ztk-enchat encrypted server client for some crude prototypes. As a matter of fact, the latest cool new APP out there seems to be something called Between, which allows realtime chat, with videos, between 2 people, it's always on connecting you to your honeybunch. :-)
What we really could use, is a version of Perl, written in javascript, which can be run in browsers as javascript. Python is already working on it, as there is an option for it in the firefox configure options.
| [reply] |
I think that you'd need to expand upon what type of server application you are intending to write?
Stevens list 9 different server designs:
- Iterative server (baseline measurement; no process control)
- Concurrent server, one fork per client
- Preforked, with each child calling accept
- Preforked, with file locking to protect accept
- Preforked, with thread mutex locking to protect accept
- Preforked, with parent passing socket descriptor to child
- Concurrent server, create one thread per client request
- Prethreaded with mutex locking to protect accept
- Prethreaded with main thread calling accept
Each have there advantages and disadvantages. Some are more applicable to some applications than others.
Salient information would include such things as:
- tcp/udp?
- How many clients?
- What volumes of data up and down?
- Are each client/server interaction totally independent of each other, or does the server need to coordinate between clients?
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Your link doesn't go anywhere.
Perhaps if you could expound on what you are looking to accomplish you might get some better answers
In general, POE is one of the most supported event loops which makes it a good candidate for Event Driven design patterns.
Do client/server applications lend themselves to event driven patters? Well, I would say that largely depends on your requirements (and of course, what you are trying to accomplish.
I will say, from personal experience, I was able to reimplement an IRC bot I had written (in one giant while(1){} loop ) in POE in several hundred lines vs several thousand lines. The down side is that the initial startup of the bot written in POE takes a bit longer to startup and start responding to input, once the bot has joined the channel, it accepts input but doens't start responding for a few moments, once it's started up and all the internal Memoization/Caching/Whatever happens under the hood/etc. I don't notice any performance issues.
On the other hand, if you're looking to implement a webserver I would point you to plackperl (which takes it cues from Python wsgi and Ruby Rack, though it is my opinion that psgi does middleware better than Ruby and Python), there is a list of servers and frameworks for web development (including a couple built on AnyEvent, AnyEvent does support POE event loops) that I really don't think it's worth rolling your own.
| [reply] |