gen_tcp的被动模式和一次模式之间的区别

我正在阅读编程Erlang 2E.在第17章的主动和被动套接字中,它说:

您可能认为对所有服务器使用被动模式是正确的方法.不幸的是,当我们处于被动模式时,我们只能等待来自一个套接字的数据.这对于编写必须等待来自多个套接字的数据的服务器毫无用处.

幸运的是,我们可以采用混合方法,既不阻塞也不阻塞.我们使用选项{active,once}打开套接字.在此模式下,套接字处于活动状态,但仅适用于一条消息.在控制进程发送消息后,它必须显式调用inet:setopts以重新启用下一条消息的接收.系统将阻止,直到发生这种情况.这是两全其美的.

相关代码:

% passive mode
loop(Socket) ->     
    ?case? gen_tcp:recv(Socket, N) ?of??    
        {ok, B} ->?     
            ... do something with the data ...?     
            loop(Socket);?  
        {error, closed}?    
            ...?    
    ?end?.

% once mode
loop(Socket) ->     
    ?receive??  
        {tcp, Socket, Data} ->?     
            ... do something with the data ...?     
            ?%% when you're ready enable the next message??     
            inet:setopts(Sock, [{active, once}]),?  
            loop(Socket);?  
        {tcp_closed, Socket} ->?    
            ...?    
    ?end?.

我没有看到两者之间有任何真正的区别.gen_tcp:recv在passive模式本质上是做同样的事情receive在once模式.once模式如何解决此passive模式问题:

不幸的是,当我们处于被动模式时,我们只能等待来自一个套接字的数据.这对于编写必须等待来自多个套接字的数据的服务器毫无用处.

zxq9.. 7

主要区别在于您选择对该套接字上的事件做出反应.使用活动套接字,您的进程会收到一条消息,带有被动套接字,您必须自己决定调用gen_tcp:recv.这对你意味着什么？

编写Erlang程序的典型方法是让它们对事件做出反应.在该主题之后,大多数Erlang进程等待表示外部事件的消息,并根据其性质对它们做出反应.当您使用活动套接字时,您可以以与其他事件完全相同的方式对套接字数据进行编程:作为Erlang消息.当您使用被动套接字编写时,您必须选择何时检查套接字以查看它是否有数据,并对何时检查Erlang消息做出不同的选择 - 换句话说,您最终必须编写轮询例程,并且这错过了Erlang的许多优点.

所以active_once和active... 之间的区别

使用活动套接字,任何能够建立连接的外部参与者都可以使用数据包轰炸进程,无论系统是否能够跟上.如果您想象一个具有一千个并发连接的服务器,其中每个数据包的接收需要一些重要的计算或访问某些其他有限的外部资源(不是这种奇怪的情况),您最终必须选择如何处理过载.

只有active套接字你已经做出了选择:你会让服务降级,直到事情开始失败(超时或其他).

有了active_once插座,你有机会做出一些选择.一个active_once插座,您会收到一个插座上的信息,并将它passive再次,直到你把它重置active_once.这意味着您可以编写一个阻塞/同步调用来检查整个系统是否安全地继续处理消息并在处理结束和receive侦听套接字的下一个开始之间插入消息- 甚至选择receive在系统过载的情况下进入而不重新激活套接字,但您的进程需要在此期间处理其他Erlang消息.

想象一下,一个名为的进程被调用sysmon,它存在于该节点上,并检查外部数据库是否正在过载.您的进程可以接收数据包,对其进行处理,并让系统监视器知道它已准备好进行更多工作,然后再允许套接字向其发送另一条消息.系统监视器还可以向侦听进程发送消息,告诉他们在侦听数据包时暂时停止接收数据包,这是gen_tcp:recv方法无法实现的(因为您要么接收套接字数据,要么检查Erlang消息,但不能同时检查两者):

loop(S = {Socket, OtherState}) ->
    sysmon ! {self(), ready},
    receive
        {tcp, Socket, Data} ->
            ok = process_data(Data, OtherState),
            loop(S);
        {tcp_closed, Socket} ->
            retire(OtherState),
            ok;
        {sysmon, activate} ->
            inet:setopts(Socket, [{active, once}]),
            loop(S);
        {sysmon, deactivate} ->
            inet:setopts(Socket, [{active, false}]),
            loop(S);
        {other, message} ->
            system_stuff(OtherState),
            loop(S)
    end.

这是实现系统范围限制的一种方式的开始,使得处理通常最困难的部分变得容易:跨网络,系统外部以及完全不受控制的元素.如果再加上一些早期的决策(比如"在完全拒绝新连接之前我们需要多少负载？"),这种能够接收套接字数据作为Erlang消息,但不会让自己受到被它们轰炸(或填满你的邮箱,使得寻找非套接字消息任意昂贵),与手动处理套接字相比,我们在石器时代(甚至今天在其他语言中)的方式感觉相当神奇.

这是LYSE的作者Fred Hebert关于过载的一篇有趣的文章:"队列不要修复过载".它并不是特定于Erlang,但他所写的想法在Erlang中比大多数其他语言更容易实现,这可能与将队列(误导)用作容量管理技术的普遍性有关.

主要区别在于您选择对该套接字上的事件做出反应.使用活动套接字,您的进程会收到一条消息,带有被动套接字,您必须自己决定调用gen_tcp:recv.这对你意味着什么？

编写Erlang程序的典型方法是让它们对事件做出反应.在该主题之后,大多数Erlang进程等待表示外部事件的消息,并根据其性质对它们做出反应.当您使用活动套接字时,您可以以与其他事件完全相同的方式对套接字数据进行编程:作为Erlang消息.当您使用被动套接字编写时,您必须选择何时检查套接字以查看它是否有数据,并对何时检查Erlang消息做出不同的选择 - 换句话说,您最终必须编写轮询例程,并且这错过了Erlang的许多优点.

所以active_once和active... 之间的区别

使用活动套接字,任何能够建立连接的外部参与者都可以使用数据包轰炸进程,无论系统是否能够跟上.如果您想象一个具有一千个并发连接的服务器,其中每个数据包的接收需要一些重要的计算或访问某些其他有限的外部资源(不是这种奇怪的情况),您最终必须选择如何处理过载.

只有active套接字你已经做出了选择:你会让服务降级,直到事情开始失败(超时或其他).

有了active_once插座,你有机会做出一些选择.一个active_once插座,您会收到一个插座上的信息,并将它passive再次,直到你把它重置active_once.这意味着您可以编写一个阻塞/同步调用来检查整个系统是否安全地继续处理消息并在处理结束和receive侦听套接字的下一个开始之间插入消息- 甚至选择receive在系统过载的情况下进入而不重新激活套接字,但您的进程需要在此期间处理其他Erlang消息.

想象一下,一个名为的进程被调用sysmon,它存在于该节点上,并检查外部数据库是否正在过载.您的进程可以接收数据包,对其进行处理,并让系统监视器知道它已准备好进行更多工作,然后再允许套接字向其发送另一条消息.系统监视器还可以向侦听进程发送消息,告诉他们在侦听数据包时暂时停止接收数据包,这是gen_tcp:recv方法无法实现的(因为您要么接收套接字数据,要么检查Erlang消息,但不能同时检查两者):

loop(S = {Socket, OtherState}) ->
    sysmon ! {self(), ready},
    receive
        {tcp, Socket, Data} ->
            ok = process_data(Data, OtherState),
            loop(S);
        {tcp_closed, Socket} ->
            retire(OtherState),
            ok;
        {sysmon, activate} ->
            inet:setopts(Socket, [{active, once}]),
            loop(S);
        {sysmon, deactivate} ->
            inet:setopts(Socket, [{active, false}]),
            loop(S);
        {other, message} ->
            system_stuff(OtherState),
            loop(S)
    end.

这是实现系统范围限制的一种方式的开始,使得处理通常最困难的部分变得容易:跨网络,系统外部以及完全不受控制的元素.如果再加上一些早期的决策(比如"在完全拒绝新连接之前我们需要多少负载？"),这种能够接收套接字数据作为Erlang消息,但不会让自己受到被它们轰炸(或填满你的邮箱,使得寻找非套接字消息任意昂贵),与手动处理套接字相比,我们在石器时代(甚至今天在其他语言中)的方式感觉相当神奇.

这是LYSE的作者Fred Hebert关于过载的一篇有趣的文章:"队列不要修复过载".它并不是特定于Erlang,但他所写的想法在Erlang中比大多数其他语言更容易实现,这可能与将队列(误导)用作容量管理技术的普遍性有关.