Ranch analysis and Learning (4)

After the previous sorting, the structure of the entire ranch framework has a clear context. Even if I am not very clear about it, you can basically understand the source code. Next I will continue to analyze the remaining files.

7. ranch_transport.erl

This file is a user-defined Erlang behavior mode. It mainly standardizes the function that must be implemented by sub-classes that implement this behavior mode. The entire function is divided into the definition of the behavior callback and the definition of the module function. module function implementation sendfile. the calling back modules defined in this behavior mode are (ranch_tcp.erl, ranch_ssl.erl) files. You can see the functions and functions of the corresponding name. I think these two files are the core module of the entire framework transmission process. It also provides a unified external interface for the gen_tcp and SSL transmission protocols to facilitate the processing of the entire framework structure. It also facilitates the expansion of transmission protocols. After protocol expansion, it can still run stably under the framework. Suppose we want ranch to support the gen_udp protocol, then we only need a module to encapsulate and process the entire protocol using gen_udp. The entire callback block of ranch_transport implements the following high abstraction for the network transmission block. Interfaces such as connection, listener, response, parameter settings, data receiving, sending, File Sending, disconnection, and shutdown are highly abstract. It can be said that cowboy can easily and seamlessly switch from http to https, thanks to the abstract processing of the entire behavior mode.

8. ranch_acceptor.erl

start_link(LSocket, Transport, ConnsSup) ->    Pid = spawn_link(?MODULE, loop, [LSocket, Transport, ConnsSup]),    {ok, Pid}.

First, let's take a look at several parameters of start_link. The first parameter connects to the socket of the listener, the second parameter selects the transmission protocol, and the third parameter connection supervision, and then starts a thread through the link.

flush() ->    receive Msg ->        error_logger:error_msg(            "Ranch acceptor received unexpected message: ~p~n",[Msg]),        flush()    after 0 ->        ok    end.

Why is the flush () function in this file? First, this function is mainly used to process messages that are not needed in our message processing, remove other useless messages, such as attack messages, from the message mailbox, and then log the probability. The entire acceptance process is a 0-Timeout process. If this refreshing process is absent, some junk messages exist in the mailbox, which leads to increasing mailbox messages, increasing memory continuously, and causing memory consumption to go down.

Finally, let's take a look at the entire main loop.

 1 loop(LSocket, Transport, ConnsSup) -> 2     _ = case Transport:accept(LSocket, infinity) of 3         {ok, CSocket} -> 4             Transport:controlling_process(CSocket, ConnsSup), 5             %% This call will not return until process has been started 6             %% AND we are below the maximum number of connections. 7             ranch_conns_sup:start_protocol(ConnsSup, CSocket); 8         %% Reduce the accept rate if we run out of file descriptors. 9         %% We can‘t accept anymore anyway, so we might as well wait10         %% a little for the situation to resolve itself.11         {error, emfile} ->12             receive after 100 -> ok end;13         %% We want to crash if the listening socket got closed.14         {error, Reason} when Reason =/= closed ->15             ok16     end,17     flush(),18     ?MODULE:loop(LSocket, Transport, ConnsSup).

The entire process consists of three processing parts: The first step is to wait for the socket accept to connect to the client, if a connection is started after the connection is processed. Step 2: Clear useless spam messages in the message mailbox. The third part is the end-recurrence call of the entire function, and continues to wait for client connection processing.

Learn the remaining modules tomorrow and organize the entire scattered thinking.