Shulou(Shulou.com)06/02 Report--

What is the role of the Ranch module, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Introduction of ranch_listener_sup module

This module is a module called by ranch and is used to handle all monitoring and network connection centers.

A child process based on the supervisor process ranch_sup started by the ranch:start_listener function when the module was created

Introduction to functional functions

Erlang's map structure # {name = > "test"} Note the distinction between two expressions: = > (which can be used to update mappings and create new mappings): = (only mappings can be updated and an exception will be thrown if the key does not exist)

Start_link: create a supervisor process and save the parameters for creating this process to ranch_server.

1.Ref listener instance alias

Creator of the 2.Transport socket process

The actual functional executor of 3.protocol

The init:ranch_listener_sup process creates a successful calling function.

Mainly did the following things:

1. Create a child process ranch_conns_sup, with three parameters passed in Ref,Transport,Protocol. The function of this process is to manage all external connections.

two。 Create a child process ranch_acceptors_sup, with the passed-in parameter Ref,Transport (optional: tcp,ssl). This process is the actual external port listener.

3. Save the process's {Ref,self () (your own process pid)} to ranch_server

4. The process starts the two processes in the way of reset_for_one, which shows that the two processes are dependent. If ranch_conns_sup fails, you must also hang up ranch_acceptors_sup and restart the two processes again.

5. In practice, the startup of ranch_acceptors_sup depends on the ranch_conns_sup process, so the ranch_conns_sup process must be started first.

Introduction of ranch_conns_sup module

Processes that accept socket connections, create Protocol processes, and monitor the exit of these processes

Introduction to functional functions

Start_link: this process is required because it is a child process created with supervisor and must have this function.

This process is not the standard of gen_server, but a process created with the original proc_lib:start_link, and the passed parameters include the parent process id,Ref,Transport,Protocol

Init: call the init function of this module through the start_link function.

This function does the following:

1. Set process_flag (trap_exit,true) to indicate that the exit information of the link module can be accepted.

two。 Set {Ref,self ()} to save data to ranch_server

3. Get the corresponding initialization information from ranch_server and TransOpts and save it to # state in the loop loop

4.proc_lib:init_ack (Parent, {ok, self ()}) this is the implementation of the internal proc_lib. The identity tells the parent process that the process has been created successfully and will return to the parent process a {ok,Pid (pid of the current creation process)}.

Loop: executes the main logic

1. {? MODULE,start_protocol, To, Socket}: socket receives the connection, sends the process, and creates the Protocol process. It should be noted when this process is created that the return value of the instance process creation process must be noted. {ok, Pid} indicates that it is responsible for the shutdown of its own process, while {ok,SupPid,ProtocolPid} indicates that the process has a conns_sup process to manage these started processes. Here ranch provides two ways to deal with it.

2. {? MODULE,active_connections,To,Tag}: get the number of connections activated by this process

3. {remove_connection, Ref,Pid}: remove connections, note here that currently only count minus one, there is no real shutdown process 4. {set_max_conns}: reset the maximum number of connections, if there is data in the sleeper, these links will be re-enabled 5. {'EXIT',Parent,Reason}: here Parent refers to the ranch_listener_sup process, and if the parent process shuts down, unconditionally shuts down all connection processes that start.

6. {'EXIT',Pid,Reason}: if the process of link shuts down, clean up pid. Note here that the pid of the process link cannot set process_flag (trap_exit,true), and the responsible person will not receive this disconnect message. If there are sleeping connection processes waiting, they are activated.

7. {system,From,Request}: call the instructions of the system. The terminate,code_change functions of gen _ server are all related to this. Currently seen to support 3 big categories, 1.suspended suspends 2.running to get some module information 3.terminating shuts down process

8. {'$gen_call', {To, Tag}, Request (which_children,count_children)}: To: the identity is From, that is, the initiator's process pid,Tag=erlang:monitor (process,Process), that is, the initiator listens to the recipient's MRef message, cancels the monitor after receiving the message, and returns the message. And such a request is made synchronously. The specific calling method is: request by gen_server:call (SupPid,which_children)

Start_protocol: this method is initiated by the socket process, creates instances synchronously, and executes the first case of loop

Active_connections: the number of active connections for synchronous requests, similar to the situation in loop 8, which can also be replaced by case 8

Handshake: this method is used in case 1 of loop, which binds the started instance process pid and socket. And verify, start the instance. If the current number of connections is full, the socket process is blocked. If the conditions are met, confirm that the binding was successful.

Terminate (# stat {shutdown=brutal_kill}, Reason,): close this process. This function is triggered by system. The system_terminate () function calls terminate and ends directly. The brutal_kill logo is directly kill off.

Terminate (# state {shutdown=integer ()}): indicates that the process shuts down indirectly, waiting for the process to kill itself.

Kill_children: kill the process directly, kill the pre-unlinke (Pid), and avoid receiving the message that the process kills

Shutdown_children,wait_children: these two functions are used in conjunction with each other. When exit is successful, you will receive the {'DOWN,process,Pid,'} message of wait_children, indicating how many processes have been interrupted.

System_continue,system_terminate,system_code_change: these three functions are called by default in the sys module in conjunction with system commands. At present, there are three main functions: system_continue: used to obtain some process information; system_terminate: used to interrupt the process; system_code_change: used to process some data update processing.

Report_error: logging errors

Introduction of ranch_acceptors_sup connection receiving Supervisor Module

Set the listening socket, distribute this socket to ranch_accpetor recipients at the same time, and listen for connections.

Function analysis

Start_link: the entrance to the startup process, using supervisor mode to start the process

Init:1. Get the connection supervisor, get the configuration information of Transport, more configured listening connections, and create a certain number of listening connection processes through one_for_one to listen for external connections.

The mechanism of recevie

% prioritize messages for {alarm,X} by setting receive after 0. Because in a receive with a timeout of 0, a timeout is immediately triggered, but before that, the system attempts to pattern match the mailbox, so this method can give priority to messages and can be used to empty all messages in the mailbox. 1. Priority matching example priority_receive ()-> receive {alarm,X}-> after 0-> receive Any- > Any end end.2. Clear all mailbox messages flush (Logger)-> receive Msg-> ranch:log (warning, "Ranch acceptor received unexpected message: ~ pairn", [Msg], Logger), flush (Logger) after 0-> ok end.

Extension: why is it that when call a process, timeout occurs, but the call process also finishes message processing?

Excerpt from gen.erldo_call (Process, Label, Request, Timeout)-> try erlang:monitor (process, Process) of Mref->% If the monitor/2 call failed to set up a connection to a% remote node, we don't want the'!' Operator to attempt%% to set up the connection again. (If the monitor/2 call failed due to an expired timeout,'!' Too would probably%% have to wait for the timeout to expire.) Therefore,% use erlang:send/3 with the 'noconnect' option so that it%% will fail immediately if there is no connection to the% remote node. Catch erlang:send (Process, {Label, {self (), Mref}, Request}, [noconnect]), receive {Mref, Reply}-> erlang:demonitor (Mref, [flush]), {ok, Reply} {'DOWN', Mref, _, noconnection}-> Node = get_node (Process), exit ({nodedown, Node}) {'DOWN', Mref, _, Reason}-> exit (Reason) after Timeout-> erlang:demonitor (Mref, [flush]), exit (timeout) end catch error:_->% Node (C/Java?) Is not supporting the monitor. % The other possible case-- this node is not distributed%-- should have been handled earlier. % Do the best possible with monitor_node/2.%% This code may hang indefinitely if the Process%% does not exist. It is only used for featureweak remote nodes. Node = get_node (Process), monitor_node (Node, true), receive {nodedown, Node}-> monitor_node (Node, false), exit ({nodedown, Node}) after 0-> Tag = make_ref (), Process! {Label {self (), Tag}, Request}, wait_resp (Node, Tag, Timeout) end end.

As you can see from the above code, the call process is monitor in the local process, and the message is sent in the way of erlang:send. At this time, receive a block to wait for the result to be returned, and then TimeOut, if it has not been returned, the error message will be returned to the process exit (timeout). Therefore, it will appear, although the timeout, the called process will still be processed, and can not be treated as the called process has not been processed.

How to avoid it? 1, avoid from the source, make sure that the call process processing information is simple enough and does not time out 2. 5%. Use cast, or! Alternative treatment

Reference website: receive with timeout in Erlang

Introduction to ranch_acceptor Modul

This module is used to receive external socket connections. And notify ranch_conns_sup to notify the business process to start and bind to the socket process

Function introduction

Start_link: the number of times to start a process with the original spawn_link function and return {ok, Pid}

Loop:1. Block the process through Transport:accept until a connection is received, and then the socket that binds the connection first goes to the connsSup, and then calls ranch_conns_sup:start_protocol to start an instance process to bind.

{ok, CSocket}: indicates that the connection is successful, and a connected socket is created for startup and binding operations

{error,emfile}: a large number of concurrent operation calls cause the number of file descriptors in the operating system to be used up instantly, and emfile. This is bound to happen if multiple connection processes and multiple external socket connections are created at the same time. I have seen in the evening that after someone has used 1024 connections, https, there will be problems, resulting in unsuccessful connections. The URL is as follows: http://erlang.org/pipermail/erlang-questions/2015-January/082446.html

{error,closed}: indicates that listening socket is closed

? MODULE:loop (_): this method ensures that the latest module function is always called when the version is updated.

Flush: with each loop, other non-accepotr messages received by the process are cleared

About the problem of {error,emfile} in the connection:

1. This error flag creates multiple linked processes at the same time, causing the operating system to run out of file descriptors in an instant.

two。 There are two types of Imax O processing, one is asynchronous and the other is synchronous. This will be relatively easy to implement under asynchronous Iripple O, and some overload protection is needed to prevent over-squeezing the performance of the underlying system.

3. Two ways: 1. Set ulimit-n 10480 2. Modify the number of handles to the / etc/security/limit.conf file

Limit.conf # * soft core 0 # * hard rss 10000 # @ student hard nproc 20 # @ faculty soft nproc 20 # @ faculty hard nproc 50 # ftp Hard nproc 0 # @ student-maxlogins 4 * soft nproc 65535 * hard nproc 65535 * soft nofile 65535 * hard nofile 65535 # End of file

4. Reference website:

[erlang-questions] {error,emfile}

Starting with EMFILE and ENFILE, the problem of fd limit (1)

The solution of EMFILE,too many open files

Record the problem here:

1. If you set the cert key, how does the client send it, and how does the server verify it?

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.