使用Ranch搭建自己的TCP连接池

上一篇我们讲了ranch的基础逻辑还看了一个简单的echo例子，这次我们尝试真正使用ranch

将Ranch集成到自己的项目中

集成部分的话参照cowboy使用rebar将ranch配置到自己项目的deps目录中即可，erlang.mk应该也可以，不过我自己没尝试过。。有兴趣的可以自己探索下应该都是共通的。这里就不再赘述集成部分了，ranch本身也说过是包装成一个易集成的结构的。

使用ranch

这里我们假设项目中已经有老的tcp接口了，我们现在换成ranch架构（没有也没关系，差距并不大，比较麻烦的都是消息的解包和登陆逻辑的处理）
这里介绍两种使用方式，一种专门起一个进程让进程阻塞在recv部分，有消息就处理，没就保持阻塞，另外一种就是每次让进程设置socket为{active, once},然后使用{tcp,S, Data} 回调来处理的逻辑,这样可以保持进程不阻塞，这种模式可以适用于gen_server模型，你可以把业务逻辑也放到这个接收进程里，虽然不推荐这样做，下面的两个具体实现都会是将消息转发给业务处理进程而不是由接收进程来处理，所以不会体现业务逻辑部分

定义ProtoCol

阻塞模式

cowboy本身就是一个典型的阻塞模型的例子，Cowboy Git库地址，但是要看懂cowboy的处理逻辑还需要了解一些http底层处理，这里我们用最简单的模型来展示ranch的使用
首先，定义我们的类似echo_protocol的tcp消息处理模块，当然他肯定是一个ranch_protocol描述的模块，也就是这个模块必然提供start_link/4并返回{ok, Pid}

这样就很简单了，我们可以根据上一篇中的echo的例子稍微进行改写，加入消息的解析，解析成自己系统可以识别的就可以了

-module(my_protocol).
-behaviour(ranch_protocol).

-export([start_link/4]).
-export([init/4]).

-record(state, {accid = 0,
    buffer = <<>>,
    pid
}).

start_link(Ref, Socket, Transport, Opts) ->
    Pid = spawn_link(?MODULE, init, [Ref, Socket, Transport, Opts]),
    {ok, Pid}.

init(Ref, Socket, Transport, _Opts = []) ->
    ok = ranch:accept_ack(Ref),
    loop(Socket, Transport, #state{}).

loop(Socket, Transport, #state{buffer = Buffer} = State) ->
    case Transport:recv(Socket, 0, 5000) of
        {ok, Data} ->
            %%改动部分
            {MsgList, NewBuffer} = prase_body(<>),
            NewState = handle_msg(MsgList, State#state{buffer = NewBuffer}),
            loop(Socket, Transport, NewState);
        _ ->
            ok = Transport:close(Socket)
    end.

%%新加逻辑
prase_body(MsgBody) ->
    prase_body2(MsgBody, []).

prase_body2(<>, MsgList) ->
    prase_body2(Left, [decode_msg(MsgBody)|MsgList]);
prase_body2(MsgBody, MsgList) ->
    {lists:reverse(MsgList), MsgBody}.

handle_msg([{login, accid, AccID}|L], State) ->
    {ok, Pid} = start_server(AccID),
    handle_msg(L, State#state{accid = AccID, pid = Pid});
handle_msg([Msg|L], #state{pid = Pid} = State) ->
    Pid ! Msg,
    handle_msg(L, State).

基础的这个版本没有解包部分，我们先假设我们的对包协议是用2字节来表示包体的长度Len，然后接下来的长度Len就是具体的打包过的包体，至于包体的打包方式，就多种多样了，可以是json或者protobuf或者其他的，保持自己项目在用的就可以，也就是上面没实现的decode_msg/1,
而start_server的账号登陆部分写的很简陋，根据自己项目进行填充即可。

gen_server模型下的非阻塞模式

-module(my_protocol).
-behaviour(gen_server).
-behaviour(ranch_protocol).

%% API.
-export([start_link/4]).

%% gen_server.
-export([init/1]).
-export([init/4]).
-export([handle_call/3]).
-export([handle_cast/2]).
-export([handle_info/2]).
-export([terminate/2]).
-export([code_change/3]).

-define(TIMEOUT, 5000).

-record(state, {socket, transport, buffer, accid, pid}).

%% API.

start_link(Ref, Socket, Transport, Opts) ->
	proc_lib:start_link(?MODULE, init, [Ref, Socket, Transport, Opts]).

%% gen_server.

%% This function is never called. We only define it so that
%% we can use the -behaviour(gen_server) attribute.
init([]) -> {ok, undefined}.

init(Ref, Socket, Transport, _Opts = []) ->
	ok = proc_lib:init_ack({ok, self()}),
	ok = ranch:accept_ack(Ref),
	ok = Transport:setopts(Socket, [{active, once}]),
	gen_server:enter_loop(?MODULE, [],
		#state{socket=Socket, transport=Transport, buffer = <<>>},
		?TIMEOUT).

handle_info({tcp, Socket, Data}, State=#state{
		socket=Socket, transport=Transport, buffer = Buffer}) ->
	Transport:setopts(Socket, [{active, once}]),
	%% 改动部分
    {MsgList, NewBuffer} = prase_body(<>),
    NewState = handle_msg(MsgList, State#state{buffer = NewBuffer}),
	{noreply, NewState, ?TIMEOUT};
handle_info({tcp_closed, _Socket}, State) ->
	{stop, normal, State};
handle_info({tcp_error, _, Reason}, State) ->
	{stop, Reason, State};
handle_info(timeout, State) ->
	{stop, normal, State};
handle_info(_Info, State) ->
	{stop, normal, State}.

handle_call(_Request, _From, State) ->
	{reply, ok, State}.

handle_cast(_Msg, State) ->
	{noreply, State}.

terminate(_Reason, _State) ->
	ok.

code_change(_OldVsn, State, _Extra) ->
	{ok, State}.

%% Internal.
%% 新加逻辑
prase_body(MsgBody) ->
    prase_body(MsgBody, []).

prase_body(<>, MsgList) ->
    prase_body(Left, [decode_msg(MsgBody)|MsgList]);
prase_body(MsgBody, MsgList) ->
    {lists:reverse(MsgList), MsgBody}.

handle_msg([{login, accid, AccID}|L], State) ->
    {ok, Pid} = start_server(AccID),
    handle_msg(L, State#state{accid = AccID, pid = Pid});
handle_msg([Msg|L], #state{pid = Pid} = State) ->
    Pid ! Msg,
    handle_msg(L, State).

emm是的这个例子是抄的例子reverse_protocol，只需要稍微改动下消息体的处理部分和state就可以完成，同样记得实现自己的start_server/1和decode_msg/1

调用自己定义的ProtoCol

{ok, _} = ranch:start_listener(my_echo, 10,
		ranch_tcp, [{port, 5555}], my_protocol, []),

将这句代码加入到项目启动逻辑中即可，同时记得把ranch加入到项目的app.src依赖中，这样就不用主动的调用ranch的启动逻辑了。

---

这里加入一点杂谈，就是为什么要在已经有“稳定”的tcp框架的情况下，再去费劲改成ranch框架呢，我只谈自己的想法，不一定适用于所有人，大家看看就好

• 首先呢，我们的另外一个deps库间接调用了ranch库，所以我不得不让ranch存在于我的deps目录，所以既然都没办法裁剪了，干脆就用了。而且ranch的使用项目也非常的多，也就意味着他经过了多个项目多个应用场景的考验，比起自己写的单项目的稳定性和各方面的考虑都是无法比拟的。
• 另外一个在与ranch的特性，ranch将每一个监听实例用一个ranch_listener_sup来管理，也就意味着一旦你接入了ranch，后续你想再使用tcp接口就相当的廉价了，你只需要像上面一样定义你的消息处理逻辑，之后一句start_litener就可以完成所有的处理，不用再操心断开，重连，数量限制这些各种逻辑，如果以后需要扩展其他的tcp接口，无疑带来了巨大的便利，我们只用重新定义一个模块，而不是重构或者直接copy代码重写一份。
• 在一个就是将来的新项目架构，你只需要更新ranch到最新版本，就可以支持最新版本的erlang特性和语法，而且是经过检验的何乐而不为呢