我正在阅读Programming 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
模式的问题:
不幸的是,当我们处于被动模式时,我们可以等待 来自一个套接字的数据。这对编写服务器没用 必须等待来自多个套接字的数据。
答案 0 :(得分:6)
主要区别在于您选择对该套接字上的事件做出反应。使用活动套接字,您的进程会收到一条消息,使用被动套接字,您必须自己决定调用gen_tcp:recv
。这对你意味着什么?
编写Erlang程序的典型方法是让它们对事件做出反应。在该主题之后,大多数Erlang进程等待表示外部事件的消息,并根据其性质对它们做出反应。当您使用活动套接字时,您可以以与其他事件完全相同的方式对套接字数据进行编程:作为Erlang消息。当您使用被动套接字编写时,您必须选择何时检查套接字以查看它是否有数据,并对何时检查Erlang消息做出不同的选择 - 换句话说,您最终必须编写轮询例程,并且这错过了Erlang的大部分优势。
因此active_once
和active
之间存在差异......
对于活动套接字,任何能够建立连接的外部actor都可以使用数据包轰炸进程,无论系统是否能够跟上。如果您想象一个具有一千个并发连接的服务器,其中每个数据包的接收需要一些重要的计算或访问某些其他有限的外部资源(不是这种奇怪的情况),您最终必须选择如何处理过载。 / p>
只有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关于重载的一篇有趣的文章:"Queues Don't Fix Overload"。它并不是特定于Erlang,但他所写的想法在Erlang中比大多数其他语言更容易实现,这可能与将队列(误导)用作容量管理技术的普遍性有关。
答案 1 :(得分:1)
利用此功能的代码如下所示:
loop(Socket1, Socket2) ->
receive
{tcp, Socket1, Data} ->
... do something with the data ...
%% when you're ready enable the next message
inet:setopts(Socket1, [{active, once}]),
loop(Socket1, Socket2);
{tcp, Socket2, Data} ->
... do something entirely different
inet:setopts(Socket2, [{active, once}]),
loop(Socket1, Socket2);
...
end.
然而,根据我的经验,你通常不会做那样的事情;更常见的是,每个插槽都有一个进程。活动模式的优点是您可以同时等待来自其他Erlang进程的网络数据和消息:
loop(Socket) ->
receive
{tcp, Socket, Data} ->
... do something with the data ...
%% when you're ready enable the next message
inet:setopts(Socket, [{active, once}]),
loop(Socket);
reverse_flux_capacitor ->
reverse_flux_capacitor(),
%% keep waiting for network data
loop(Socket)
end.
此外,写一个"真正的"在Erlang / OTP应用程序中,您通常会编写gen_server模块而不是循环函数,并且在handle_info
回调函数中可以很好地处理TCP消息以及其他消息。