系统技术非业余研究

Erlang的代码是先翻译成abstract_code,再到目标代码的，如果有符号信息很容易恢复源代码，通常我们部署系统的时候需要把符号信息去掉，reltool就可以干这个事情！

我们演示下：
Read more…

gen_tcp:unrecv是个未公开的函数，作用是往tcp的接收缓冲区里面填入指定的数据。别看这小小的函数，用起来很舒服的。
我们先看下它的代码实现，Erlang代码部分：

%%gen_tcp.erl:L299
unrecv(S, Data) when is_port(S) ->
    case inet_db:lookup_socket(S) of
        {ok, Mod} ->
            Mod:unrecv(S, Data);
        Error ->
            Error
    end.
%%inet_tcp.erl:L58 
unrecv(Socket, Data) -> prim_inet:unrecv(Socket, Data).

%%prim_inet.erl:L983
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                                              
%%                                                                                                                          
%% UNRECV(insock(), data) -> ok | {error, Reason}                                                                           
%%                                                                                                                          
%%                                                                                                                          
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%                                              
unrecv(S, Data) ->
    case ctl_cmd(S, ?TCP_REQ_UNRECV, Data) of
        {ok, _} -> ok;
        Error  -> Error
    end.

运行期c代码部分:
Read more…

最近有同学在gmail上问关于gen_tcp发送进程被挂起的问题，问题描述的非常好，见底下：

第一个问题是关于port_command和gen_tcp:send的。从项目上线至今，我在tcp发送的地方遇到过两次问题，都跟port_command有关系。

起初程序的性能不好，我从各方面尝试分析和优化，还有部分是靠猜测，当初把全服广播消息的地方，换成了port_command，当时参考了hotwheels的代码和您的一遍相关博文。

根据您的分析，port_command应该比直接用gen_tcp:send高效的，并且没有阻塞。但是我却在这个地方遇到了阻塞，具体表现如下（两次，分别出现在项目不同阶段，下面分别描述）

项目上线初期：

当时玩家进程给玩家发消息用的是gen_tcp:send，广播进程为了高效率用了port_command。当活跃玩家到了一定数量以后，玩家无法进入游戏，分析原因，是全局发送广播消息的进程堵住了，从message_queue_len可以看出来，改为广播进程给玩家进程发消息再让玩家进程给玩家自己发消息后，状况排除。

最近一段时间：

这时候玩家进程的tcp发送数据，已经被我替换成了port_command并运行了一段时间都没问题。但是一些流量比较大的游戏服，活跃玩家到了一定数量以后，消息延迟很大（5-6秒），做任何操作都卡，在出现状况期间，服务器CPU、内存、负载各项指标并未异常，ssh连到服务器操作也很正常，没有任何卡顿现象。同服务器的其它游戏服也都正常，但是出问题的游戏服的整个erlang节点都进入一个“很卡”的状态，体现在我进入erlang shell中进行操作时，输入文字延迟很大。

起初我没怀疑过port_command有问题，所以我到处找原因和“优化”代码，这个优化是加了引号的。

但是最后，在一次服务器同样出现状况很卡的时候，我把tcp发送数据的代码改回了gen_tcp:send，并热更新了相关模块，服务器立即恢复正常。

我一直对上面的情况百思不得其解，我之前写的代码如下：

tcp_send (Socket, Bin) ->
try erlang:port_command(Socket, Bin, [force, nosuspend]) of
false ->
exit({game_tcp_send_error, busy});
true ->
true
catch
error : Error ->
exit({game_tcp_send_error, {error, einval, Error}})
end.

希望您能帮忙分析下是什么原因导致整个erlang节点都卡的，我想这对其他的erlang程序员也会有帮助!

关于这个问题我之前写了篇文章，系统的介绍了gen_tcp的行为，gen_tcp:send的深度解刨和使用指南(初稿)见 这里
Read more…

Erlang集群二个节点之间的通讯是通过一个tcp长连接进行的，而且是全联通的，一旦cookie论证通过了，任何一个节点就获得全集群的访问权，可以参考Erlang分布的核心技术浅析
。erlang的这个授权模式特定搞的这么简单，但是在实际使用中还是有安全性的问题。我们退而求其次，来个IP网段限制，这个功能Erlang是有的只是没有文档化。
Read more…

Erlang的集群是由各个节点组成的，一个节点有一个名字来标识，而不管这个节点在网络的物理位置，所以在部署Erlang集群的时候就很方便。只要在集群里新启动一个节点，给个相对固定的引导的节点，让新节点和这个引导节点取得联系，由引导节点把新节点介绍入集群就OK了。
在实践中，新采购的机器上通常配置好IP,以及ssh访问权限。 我们需要在新机器上手工安装Erlang系统，部署新应用，然后启动应用节点，加入集群服务，这个步骤很繁琐。我们希望能够自动化去做这个事情。common_test的ct_系列模块来救助了。
common_test是A framework for automated testing of arbitrary target nodes，它随带的ct_ssh可以透过ssh在远程机器上执行各种各样的shell命令，通过scp传输数据;而ct_slave非常方便的可以连接到远程机器启动一个erlang节点。
pool（www.erlang.org/doc/man/pool.htm）模块也可以远程启动节点，但是它要依赖于操纵系统的ssh工具，需要在机器之间做ssh互信，也就是说ssh targetip这样的不能出现任何的交互,比如说键入密码,很不方便。

我们首先来演示下如何在远程机器上执行ssh命令：
Read more…

今天有同学在gmail里面问了一个Erlang的问题，问题描述的非常好, 如下：

问题的背景是：

1、我开发了一个服务端程序，接收客户端的连接。同一时刻会有多个客户端来连接，连接后，接收客户端请求后，再发送响应消息，然后客户端主动断连。

2、服务端监听的socket属性设置如下：

[binary, {packet, raw},
{ip, IPAddr}, {backlog, 10000},
{active, false}, {reuseaddr, true},
{nodelay, false}, {delay_send, true},
{recbuf, 128 * 1024}, {sndbuf, 64 * 1024}]

3、服务器accept监听socket，接收客户端请求，发送响应消息分别是在3个不同的进程中进行。接收请求和发送响应的进程都是重复使用的，每次重新使用的时候传入一个新accept的socket。

问题的现象是：

1、单个用户发起呼叫的时候，流程是成功的，服务器能正常响应。但是多个用户一起呼，批量跑的时候，跑一段时间后，部分客户端会发现不能接收到服务器返回的响应。从抓包来看，客户端的请求是发送到服务器端了。

2、服务器这边发送响应的进程会收到一条{empty_out_q, #Port<0.25876>}这样的消息，而这条消息并不是我开发的代码产生的。

问题是：

1、为什么发消息的进程会收到{empty_out_q, #Port<0.25876>}这样的消息？

2、收到empty_out_q消息，是不是就说明调用gen_tcp:send发送失败？

3、是不是说设置了delay_send的属性，所以即使send失败，也是异步的，在调用send的时候会马上返回ok，但是后面真的发送失败后，则系统会给调用send方法的进程发送一条{empty_out_q, #Port<0.25876>}这样的消息。

这个问题非常有意思。 Read more…