I want to use Erlang for some background processing and stuff for a web app. I read about its concurrency handling and stuff and I have started learning it. What I want to do specifically is a persistent connection with the clients using COMET - with the Erlang process co-ordinating the HTTP client connections.
Do I need a Erlang based web server for this?
For the actual implementation, how does the "spawn"-ing work in Erlang. I downloaded the erlang ebook and read about spawning. In the case for my web based script, when two clients connect to the same Erlang script by making an HTTP request - can I automatically "spawn" new threads for each of them, and do message passing?
No, you didn't but it is simplest way. You can combine Erlang with libevent to achieve more http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3/
Yes, spawn new client is cheap, if you want cheaper see above.
I would highly recommend using an erlang based webserver to handle the comet connections. The lightweight processes in erlang are half the benefit of using it for this type of thing.
Most of the erlang webserver frameworks will handle the spawning for you. No need to reimplement it yourself. See nitrogen and mochiweb for examples of really dead simple comet implementations.
Did you see the page http://beebole.com/erlang ?
It contains:
how to setup an Erlang environment(with Mochiweb) on Ubuntu
how to install the Nginx web server
a video tutorial to build a small web app using Erlang
You should investigate 'YAWS' (high performance HTTP server) modules: easy to write, full flexibility. YAWS is easily installed: apt-get install yaws (on Ubuntu at least).
Another option would be to use Nitrogen - this allows an easy integration of Erlang code in web pages, including a fully-fledged webserver, and comet.
Related
I would like to know which server is the best to use for the Nitrogen Web Framework?
Of the 5 listed on the site, I have already removed Inets(not recommended for production) and WebMachine. Left with only Mochweb, Yaws and Cowboy. I also noted on the site that Nitrogen/Yaws windows binary is not available for download. Any particular reason?
There is no clear answer for what is the "best" to use. If you're just getting started, just pick one and go. Cowboy and Yaws are under the most active development as "full featured" Erlang webservers, and so if your limitation is to use Windows, just use Cowboy.
Each server has its own configuration for tuning, and if you're comfortable tuning and developing for one, Nitrogen provides the mechanism to use your server of choice.
As for not providing a Windows download for Nitrogen/Yaws, Yaws is not done in "pure erlang" (there are some C files that need compiling), and as a result, compiling Yaws on Windows is more complicated, so in order to just get the build out there, Yaws was left out on Windows. Enough time was spent optimizing Nitrogen's build in Windows that I just wasn't going to spend any more time trying to get Yaws running with Nitrogen on Windows. I wanted the release done, and so Yaws was left to the wayside for a future version.
Let's assume we have a web project in which we want to have ~10000 web clients connected to the server simultaneously. Let's also assume that one client session lasts about 25 minutes.
If we compare LAMP stack or any other popular web stack/framework (Ruby on Rails with Apache on Linux, etc.) to a web project built in Erlang/OTP - what does Erlang/OTP have in terms of fault tolerance that other frameworks don't?
What event can happen to a client that will cause the whole LAMP stack crash, while Erlang/OTP will stand its ground?
Note that a typical LAMP-stack does employ some fault tolerance. In particular, if a request in the LAMP stack fail, only that request will, while the rest of the code will run on. This kind of protection allows you to have faults in a single request without that hurting other requests.
Erlang provides this idea of "able to cope with smaller unforseen errors" at a much finer grained scale. You may have other subsystems in an application, and the same kind of tolerance to errors can be extended to those. You won't get it "for free", but the tooling is there to build a system which is robust. Imagine a client error in the LAMP stack. This will often lead to a disconnect of that client. It may not be so in Erlang and the client can keep on running.
For a system of 10000 clients, Erlang provides the advantage that you can have a process per client. Or perhaps 10 processes per client. That is much harder to pull of in many languages since a process/thread is rather heavy and expensive. Note that interprocess communication between the clients are easy, also if some clients are on another machine (imagine extending to a distributed cluster some day).
If you write your code in a certain way, you can make sure that if a client crashes, for one reason or the other, then its state is properly cleaned up by other processes. That can avoid lots and lots of small nasty leaks in state as well.
what does Erlang/OTP have in terms of fault tolerance that other frameworks don't?
Now, Erlang/OTP has very minimal if not, Zero side effects. Because of its concurrency, a web server like yaws literally spawns a small web server for every connection. If one user is affected by a given web service fault in your application, all other users will never notice and the only that users process may exit.
With OTP, you can build applications with a number of supervisors, such that if a server goes down, its restarted and many other functions and options you may need.
Erlang's distribution allows us to write distributed applications. I have personally used yaws web server in building a web application.
My experience is that which ever web server you may pick, say Mochiweb, a tutorial found here: http://alexmarandon.com/articles/mochiweb_tutorial/, is quite impressive in performance. Infact, a few years back, the oldest version of yaws web Server was bench marked with the (then) newest version of Apache, and the results of the bench mark are very awakening. When i went through a million user comet application with Mochiweb, which has Part 2 and Part 3, i was impressed. These are some of the few examples of powerful web frameworks built for the web.
And by the way, have you heard of these new NO SQL Databases with REST (HTTP) interface developed in Erlang/OTP e.g. Membase Server [home page here: http://www.couchbase.com/products-and-services/membase-server], Couch DB, and Riak, their performance is very impressive, meaning that their web/REST interface is very stable and due to their impressive , documented write through put, they have proved that their underlying Technology (Erlang/OTP), was built not only for high availability and fault-tolerant systems only, but for the web too! Just read through this document: http://blog.couchbase.com/why-membase-uses-erlang
Many more web frameworks built in erlang and are very impressive can be found listed on the wiki page here: http://en.wikipedia.org/wiki/Erlang_(programming_language). A probably better summary of its features that make it powerful on the web can be found in here: http://cs.nyu.edu/~lerner/spring10/projects/Erlang.pdf
On non-web based chat system the server distinguishes its clients by their PIDs, right? And what should be used to distinguish the clients on web-based chat system?
Thnx in advance
The fact that you're using a web server shouldn't change much about your model. You're still building chat. You also don't want to make your chats tied too deeply to the process that is managing their HTTP connection. HTTP connections are ephemeral, even if everything is going well and you're using long polling there's no guarantee that the connection will be re-used with Keep-Alive for the next long poll. The user might also want to open up the same chat in multiple browser windows, multiple computers, whatever.
I haven't looked closely at any of these but you're not the first person that has built web chat with Erlang:
http://chrismoos.com/2009/09/28/building-an-erlang-chat-server-with-comet-part-1/
http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
http://yoan.dosimple.ch/blog/2008/05/15/
https://github.com/yrashk/socket.io-erlang (more of a general tool for this sort of thing, not chat specifically)
https://github.com/rvirding/chat_demo (as seen above)
I think the confusion comes from the notion that a Erlang server process must stay alive for every individual client. It can, but Mochiweb doesn't do that by default if I'm not mistaken. It just spawns a new process for every request. If you would like to have a long lived bidirectional client <-> server process connection you can do that for example by;
sending a client identifier with every request and map that to a long-lived process on the server. The process will maintain servers state and you can call methods on it. It's still pull and not push though.
use the web socket implementations. Not sure if Mochiweb has one, but other Erlang HTTP servers like Misultin and Yaws provide one. For a web based chat system I believe web sockets would be a great fit.
For a very trivial example of a web-based chat system using websockets and Misultin you can check out this chat demo. It was written to demonstrate an idea and is not very elegant, but it does work.
i am completely new to ejabberd. I have downloaded the installation for both windows and linux (Ubuntu). Somewhere on the web i had seen a demo of how to install and set it up but the installation was configured as a 'demo'. I have the pidgin XMPP client and now am having problems setting up ejabberd.
Another issue is that i have tried to develop chat systems with Nitrogen's comet pools and erlang ETS tables on the backend (thanks to the failover mechanism embedded in ets tables now) i.e ets:give_away/3 [it gives my chat engines fault tolerance, thanks to the guys who maintain the virtual machine who saw how useful this is]
Can we have Web interfaces to ejabberd servers, putting aside its admin interface. Nitrogen Comets are quite cumbersome sometime forexample, the browser time out especially in Nitrogen 2.X.X can not easily be changed.So now i have decided on ejabberd. How can i customize an internal organization chatting system using ejabberd as the backend engine. I wouldnot want every one in the organisation to download Pidgin as a client but want to embed the chat functionality in the web interfaces.
With Erlang, Yaws, Mnesia, Inets, Mochiweb e.t.c i have no problem so even if it requires me to develope an erlang application with a few Gen servers on top of ejabberd, that wont be a problem
Please point me in the right direction to get ejabberd up and running. On the processOne Website and the ejabberd documentation i have still failed to start it well. Please help
If you are a newbie and want to setup and ejabberd server, you should simply use hosted version of ejabberd.
You can easily create your own domain on http://hosted.im
You should be up and running in minutes
I have a server and some clients (about 50) in an intranet. The clients send short (about 40 character) string data to the server and the server answers with a similar string. There are up to (but not permanently) 2-3 requests per second for each client. The server has to serialize the requests to get the response strings.
The system should have as less as possible impact on the network as possible (i.e. the server may run something like a webserver already). It should be as easy to install and administer as possible.
What are the possibilities to achieve this using Delphi (Client: D7, Server up to D2010)?
I use the Synapse library for such a simple server. Its lightning fast, very light, and threads easily. The demo Echo in the main synapse install is a fantastic start for what your trying to do. If you are going to be performing database access inside each request/response thread then I strongly also suggest looking at the connection pool example by Cary Jensen to keep your database connections in check.
TCP, definitely. But I'd like to give a vote for ICS. Never liked Indy ...
What about Indy's TIdTCPServer and TIdTCPClient? They provide command handlers, which makes implementing text-based protocols very straight-forward.
There are a lot of options.
Ultimately, I agree with Smasher and like using sockets. They're quick, easy and portable. If you're dealing with a fairly simple protocol and don't need a full n-tier solution, creating a TCP or HTTP server application is dead simple, very light weight, and easy to make compatible with any client. You can even add SSL support to these stand alone applications without having to configure a web server or interfering with it, if it's already running on the same box.
I use RemObjects SDK for this sort of purpose. It takes care of all the difficult stuff, and I just ask it to connect and make function calls to pass the data.