Erlang distribution is built into the language and is completely transparent from the user's perspective. Accessing a process by its process ID works the same whether it refers to a process on the local computer or a process on a system elsewhere in the world.
Distributed systems in Erlang
1. The essence of a distributed system is to provide a certain service in a transparent way through some computers, processors or cores connected by a network. Services can be specific, such as the storage function provided by a distributed file system or database; or general, such as a distributed operating system that provides functions normally provided by an operating system through a computer network. Distributed can be thought of as tightly coupled parallel processors, or more specifically a grid of loosely coupled electronic science systems. Erlang provides distributed programming capabilities, enabling Erlang systems to run in a network across Erlang nodes.
2. Distributed system:
Ejabbered: This is an Erlang open source Jabber-based instant messaging (IM) server. It implements a cluster of two or more Erlang nodes. These nodes reside on the same or different machines and support each other through message and event load balancing. If one of the nodes dies due to a software or hardware error, or simply a memory leak, the other nodes will take over their traffic and hide the error from the end user. In the worst case, end users can realize they have managed a network glitch when the socket reconnects to a new node, but all they notice is the logout and login of other users.
Erlang Web Framework: This is an open source application for Erlang-based web applications that gain scalability and reliability by using distributed. A typical cluster consists of front-end and back-end nodes. The front-end nodes include the web server (running in the Erlang node), a caching layer, and XML parsing for the inner layer to handle requests. It also contains functions to handle the dynamic generation of XHTML. Two or more backend nodes contain the database and all the glue and logic needed to generate dynamic content. The real load is on the front end as it handles the socket linking and most of the parsing. To scale the system, all that needs to be done is to add hardware and front-end nodes, adding support for the back-end only when necessary. If any node fails, the load balancer will automatically redirect traffic to the surviving nodes.
AXD301 ATM switch (one of Erlang's flagship products): The smallest Erlang cluster consists of two nodes, one called the call establishment node and the other called the operation and maintenance (O&M) node. If the O&M node fails, a failover occurs and the O&M application is restarted on the call establishment node. When the O&M node returns to normal, through automatic recovery and manual intervention, a takeover will occur, and the O&M application will be transferred back to the original node to continue running.
The failure of the call setup node is an emergency because they can affect ATM communications. If a call setup call setup node fails, a failover will transfer all call setup applications to the O&M node. Distributed data guarantees that any call's resume is initialized before failover and no call is lost. A new call setup application running on the O&M node takes over them. When the original node is rebooted, to ensure that communications are not disrupted and no call setup requests are lost, a takeover by an O&M application will migrate the O&M functionality to the new rebooted node, and the call setup functionality remains on the previous O&M node superior.
3. Concurrency is at the heart of all distributed systems, because operations and communications run in parallel in a system of processors and networks. The main challenge of distributed systems is the robustness of the system in the event of an error.
4. Building a distributed system has numerous benefits:
Can provide on-demand growth performance. A classic example is a web server: if you plan to release a new partial version of a software, or plan to stream a football game video in real time, these servers can be distributed over many machines, making this possible and not having question.
This performance can be guaranteed by duplication of the service - in this case a web server - which is often seen in distributed system architectures.
Replication can also provide fault tolerance: if one of the replicated web servers fails or is unavailable for some reason, HTTP requests can still be handled by the other servers, albeit at a lower rate. This fault tolerance makes the system more robust and reliable.
Distributed allows transparent access to remote resources and, based on this, provides services to all users by uniting disparate systems as a whole. Modern e-commerce systems provide this collection of methods, such as the Amazon.com website.
Finally, the distributed system architecture makes the system scalable and enables other services through remote access.
Distributed Computing in Erlang: The Basics
1. An Erlang node is a named running Erlang runtime system. Multiple nodes can run on the same host, but also on different hosts.
2. To run a node, the erl command requires the sname tag (the name tag can also be used). Note that the prompt in the Erlang terminal shows the node name and hostname, which is called the node's unique identifier.
erl -name foo.
To understand what's going on below, take a look at the dist.erl module, which contains the function t:
t(From)->From!node().
This function takes the process identifier From as an argument, and its single action is to send a message to the process represented by this identifier. This message is the result of a call to node(), which returns the identifier of the node on which the call was made.
3.spawn/4 function (the first parameter is the node where spawn should happen, the remaining three are similar to spawn/3: module, method and initialization parameter)
1. The process is spawned on the node bar@STC and starts executing function t, the other takes the process identifier of the terminal running on foo@STC as an argument.
2. The effect of this is to send the value of the node() function (ie the identifier of the current node, in this case bar@STC) to the process identifier, and the function t then terminates.
3. Here can be tested by flushing the message remaining at foo@STC, which shows that it has sent the identifier bar@STC.
4. The format of sending a message by command between two nodes is exactly the same as in the non-distributed case: Pid!Message. Furthermore, the transmission of messages from one node to another keeps the same order as they were sent. The only difference between this and the non-distributed case is that the remote node may be invalid.
5. Note: Sending a message to a named process differs from the non-distributed case, because in a non-distributed environment the naming is local. Therefore, to send a message to a process called frequencyy at node foo@STC, use {frequency,foo@STC}!Message.
Node name and visibility
1. If a node can communicate with other nodes, it is called a live node; another way of saying it is that this node is nameable, so it can participate in communication.
2. The function erlang:is_alive() tests whether the local runtime system is alive.
3. Use the net_kernel module function to change the survival state of a running system (net_kernel:start([node name]) sets the system's survival state to true, net_kernel:stop() sets the system's survival state to false), You can also use the node/0 built-in function to find out the name of the current node (node()).
4. Any surviving nodes must be named: on that host, these names must be unique, but on different hosts, names can be repeated. This name/host pair is called a node identifier and is used to uniquely identify a node in the network.
5. Names come in two forms:
Short name: erl -sname foo ...
sname names a host on the local area network and is given as name@host (eg foo@STC).
Long name: erl -name foo...
This name gives the full IP address of the host: it can be [email protected] or (on a LAN) [email protected]. If you use the net_kernel:start function to start a distributed node, the node will be given a long name.
6. Note that long name nodes can only communicate with other nodes with long names, and short names can only communicate with other nodes with short names.
7. Note: In order to use the hostname of the form server.keng.ac.uk instead of the original IP address such as [email protected], the hostname needs to be resolved to an IP address. A Domain Name Server (DNS) can do this, but if the DNS server is not accessible, the name can be resolved locally using the information contained in the hosts file. The exact steps to be done depend on the different platforms.
Communication and Security
1. For communication between two nodes, it is not only necessary for both nodes to be surviving nodes, but also to include shared information in a primitive called a security identity letter. Each node has only one cookie at any time, and nodes sharing the same value can communicate.
2. Each node can specify a certain cookie at startup, such as
erl -sname foo -setcookie blah
If there is no preset value at startup, the Erlang runtime system will choose a value stored in the .erlang.cookie file. If the file doesn't exist, it creates one in the user account's home directory. A randomly generated secure cookie is stored there. This way, nodes created with the same user account share the same cookie by default. If you have experimented with distributed Erlang without setting cookies, take a look at the erlang.cookie file. It can be edited with the desired value.
3. When a distributed node on a computer establishes a connection with another remote node through a shared cookie, the owner of the remote node also has the same user access rights as the account under which the local Erlang node runs.
So never expose Erlang node names and cookies to anyone unless the core of the network has been tuned to deal with serious security concerns, or the person is unequivocally trusted not to do anything malicious.
Communication harmony
1. The most basic communication is a node testing whether it can establish links with other nodes, which is informally pinging other nodes.
2. Communicate through net_adm:ping/1:, pang replies that the communication fails, the pinged node will also give an error report to signal the connection request, indicating that a potential security problem has occurred by warning, The pong reply indicates that the ping was successful: such a successful attempt does not notify the bar node.
node connection
1. As long as distributed Erlang nodes share the same cookie information, they can communicate with each other, and the Erlang runtime system establishes a connection the first time a node is referenced. This can be done by calling net_adm:ping/1 or by sending a message to one of its registered processes. For nodes connected together, information is shared by default. So, if A knows B and B knows C, then A can also find C.
2. Each node has a cookie at any one time. Security in distributed Erlang is based on shared cookie information.