World: r3wp

Although it is possible to take advantage of multi-core technology 
by running several applications processes in parallel, the real benefit 
would be for multi-threaded applications. The challenge then is to 
change single-threaded or sparsely threaded applications into multi-threaded 
and also to debug them.

Erlang has unique properties for taking 
advantage of multi-core technology
One of the fundamental properties 
of the Erlang language is built-in support for very light-weight 
processes, each with its own memory, and using explicit message passing 
for their communication. Because of this most applications written 
in Erlang are realized as a number of cooperating Erlang processes 
representing something in the problem domain of the application, 
for example active call sessions, connections or transactions. Typically 
this will result in many thousands of simultaneously executing processes 
in a heavily loaded application.

The parallelism already present 
in most Erlang applications makes them ideal for taking advantage 
of multi-core technology, without there being any need to modify 
them.

The only thing needed is an Erlang virtual machine (VM) which 
works in a multi-threaded way, and that is what we now are releasing 
in Erlang/OTP R11B.

Yep, cooperative multitasking built-in. Maybe we'll get that in R4 
;-)

Cheyenne, with its mono-thread full async engine, would scale very 
well on a similar benchmark, probably much better than Apache, but 
less than Yaws I guess. OTOH, a bench testing raw throughput, would 
show Apache performing quite better than Cheyenne (maybe 2 or 3 times 
better). It's hard for interpreted REBOL to compete with compiled 
C on raw power. I think that it would be possible to reduce this 
difference to 1.5 with deep optimization in Cheyenne (task scheduled 
for v1.1 according to my roadmap). R3 should open new perspectives 
for speed & memory optimizations (threading, clean async kernel, 
optimized ports, Rebcode, plugins...).

Erlang has a lot going for it, but it has its own set of issues as 
well. Maarten recently spent some time evaluating it quite deeply 
for me. At this point, we're sticking with REBOL.

It is *very* attractive, all the stuff you get basically for free, 
in the context of building distributed systems.

Interesting Gregg, could you say more on what pros and cons made 
you take the decision?

Where's the whitepaper?  :)

Never noticed this before.. seems someone was considering using Rebol 
as the GUI for Erlang
http://erlbol.dougedmunds.com/

Interesting :-)

Was? That's a new project :)

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Hi Gregg,  which is the project you're talking about  ?

Doc, the 64K limit is the limit on the number of server ports but 
not the number of connections that can be open to a single port like 
port 80

AFAIK, every client or server connections are taking a port number 
in the 64K range. Each time a server receives a new connection it 
assigns a local port number to the client connection. That local 
port number is in the 64K range because TCP (or UDP) header storage 
space for source or destination ports are only 16bits each.

In theory, a combination of a client IP and a local port (in the 
64k range) could make a unique key allowing to handle more than 64k 
clients, but I don't think that the big 3 OS are able to exploit 
such trick in their default configuration.

There is a paper on Philip Wadler's site: http://homepages.inf.ed.ac.uk/wadler/documents/ServiceArchitectures.pdf


Check footnote 32 on page 21 (chapter 13). That's what stopped us.

doc, in erlang concurrency is supported in the programming language 
(i.e. does not use the os mechanisms). I am trying to track down 
a reference were it explained you could have 2 power 32 connections 
theoretically

Maarten, yes you can set the secret cookie but if one system is compromised 
the whole distributed system is. how is that different in other architectures 
?

Unless Erlang implements its own TCP/IP stack, he will hit OS limitations, 
even if, internally, he's able to handle 2^32 connections. Anyway, 
I'm interested in reading such paper if you find it.

not found the paper yet but here is an answer i found on the net

Pat e wrote:
> Can anyone tell me how can Yaws have almost 80,000 concurrent

> connections, and some "home-made" erlang servers over 110K concurrent
> connections if there are only 64,000 tcp/ip ports?

A TCP/IP connection is identified on each host by a
(local port, local IP, remote port, remote IP) tuple.


Therefore, there can be more than 2^16 connections to a server (even 
if

the server is listening on a fixed port) provided that they are from 
more
than one client.


In theory it's also possible to have more than 2^16 connections between 
a

specific pair of hosts provided that they use all of the available 
port

combinations. However, TCP/IP stacks generally do not support reusing

local port numbers (when the port is not specified by the client 
software)

by default, so the practical restriction in this case may still be 
2^16.

-- 
David Hopwood

Sorry, but possible number of theoretical connection numbers is totally 
stupid reasoning for whatever kind of decision :-)

Handling 64,000+ concurrent clients is a problem I wish I had.

Yep, in real world, there's no point accepting more than 10k connection 
on a single server. You usually hit memory and cpu limits far before 
reaching that limit. Spreading the load among multiple servers is 
the way to go. That's why the Yaws vs Apache benchmark sounds so 
theorical and irrelevant to me.

theorical => theoretical

I like "theorical", it sounds like "the oracle". :-)

the yaws vs apache benchmark is more an example on how the erlang 
service can handle DoS

hi doc, I have a c++ backg. and seen plenty fo 30k+ concurrent but 
yes for web sites its common to have a hw redirector and multiple 
servers

I'm back at asking this -- how do I obtain the original request string 
-- e.g.  "/wiki/show/This_Page" within the CGI environment?  'path-info 
only gives me the translated filename (always '/qm.r' for my app)

Chris, you should test using http://localhost/show.cgiscript it 
will display all CGI data. 'script-name should give you what you 
need.

There must be:
	set 'NT-service? false

in misc/os.r in the block where the 'library component is not found. 
(to be able boot with Rebol/Core)

Let's say I need some functions available for all CGI scripts, where 
is the best place to init them?

(if I don't want to init them in all cgi scripts)

CGI environment is not supposed to be persistent, so there's no other 
ways than to manually add libs loading code to %CGI.r script. If 
you're encapping Cheyenne, you can add your libs to %cheyenne.r (and 
don't forget to LOAD them too). If you need a persistent environment, 
use RSP instead.

Thanks for the 'NT-Service? fix, it will be included in the next 
release.

Think we might try using Cheyenne as a personal web server, providing 
functionality similar to Adobe Air, Google Gears for our product.

Here's a little video clip of a prototype in action.. 
http://kommonwealth.com/video/cheyennewidgetdemo.swf

That's all taking place in the browser, being served up from our 
server.. and accessing a copy of Cheyenne running locally. No cross-domain 
issues here :)

Firewall problems? You have to allow listening port ... but - that 
should not be problem for 99% of users imo ...

Flash has very strict security. You have to setup it correctly to 
anable cross-domain functionality. It's not bad if you understand 
how it works.

It has nothing to do with Firewalls.

http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf
(but it's not related to Cheyenne)

Basically it's the part which was showstoper for Rebol plugin - shortly 
it works in a way, that if you want to connect to some site with 
Flash, Flash first loads crossdomain.xml file from the target server 
where must be your domain allowed to access the server domain. If 
it's not allowed, the Flash do not connects at all. It's a basic 
prevention of doing Dos attacks from Flash Player.

I'm not sure what is Terry doing, but of course you can use Rebol 
to connect from Flash to services on servers from not allowed domain 
as with Rebol you can change the request header easily.

what are you talking about, Oldes? And yes, it has something to do 
with firewalls. The thing is - noone was talking flash here ;-)

Terry imo wants to use Cheyenne as local web server, and to allow 
their kommonwealth to run locally cached, or something like that 
- but still - his technologies are html, css, js, ajax ....

yeah, Pekr's right.  There's no flash there. 
I suppose the firewall would be an issue for some.

DocKimbel, small request: Would it be possible to post the rsp guide, 
cheatsheet and docs as separate pages directly on the site? It's 
unpractical to have to download Cheyenne every time I switch machine, 
just to read the docs. Thanks.

stick them on google as a googledoc :)

Henrik: good suggestion