云风

想到一种解释： 因为你限制了最大连接数 256 ，如果被占满，会导致 ACK 请求被搁置。一旦超时，ACK 会任务不健康，然后转而不再转发。 建议： 1. 给 ACK 的 IP 设立白名单 。 2. 到达最大连接数后增加 log 。 3. 排除潜在的服务过载问题（找出超出 256 的可能性）。

我觉得你可以在 http.tlshelper 模块内多加一些 log 帮助分析到底发生了什么事情，收发了怎样的数据。 我们最近一年用 skynet 做了一些内部用的非常高负荷高流量高并发连接的服务，暂时没有发现网络层有什么 bug 。我认为可以信任网络层的实现。 倒是在处理高流量复杂的业务时，需要做一些流量控制操作，避免把数据堆积在网络层造成 OOM (out of memory) 问题，这就是最近新添的 api 的作用。 倒是 tls 可以多测试一下。但是有好些朋友使用基于 tsl 的 websocket 服务，似乎没有类似反馈。 我倾向于认为首先是 ACK 出错，导致阿里云判断健康有问题，从而停止了端口转发，继而造成玩家 lag 。

lts.c 问题需要 @lvzixun 来看。 不过该模块是一个纯 C 模块，不涉及网络 api ，它只负责处理数据。也就是说，不应该在 C 模块内部有任何阻塞。如果能增加更多 log 显示 lts.c 的内部的信息可能可以帮助排查问题。 阻塞一定发生在 lua 层，任何 c 层次的阻塞都会触发监控 log 。这个现象更像是 lts.c 模块需要的网络数据没有收全，导致 block 在 lua 层的 socket.read 上。

我建议可以把 https://github.com/cloudwu/skynet/blob/master/lualib/http/tlshelper.lua#L7 这里这个 socket.readfunc 包装一层，单独加上额外的 log ，观察在阻塞发生的时候的数据流。

1.3.0 版本 socket 没有 pause/resume 机制，在两端收发不对等时，容易出问题；另外，没有对半关闭状态妥善处理。 ps. skynet 版本更迭很少破坏兼容性，所以提倡尽量用 github 最新版本，勤更新比长期大更新更少出问题。现在没有维护特定稳定版的计划。

我不认为这是 skynet 的问题。 死锁发生在 freopen64 里，你可以 google 到一些关于 freopen 和 fclose 发生 deadlock 的问题（例如：https://www.cygwin.com/bugzilla/show_bug.cgi?id=24963 ）。你可以尝试升级 crt ，看是否有 bug 需要修复。同时也检查进程打开文件数目有没有超过上限。 另外，freopen 只发生在 binary 文件中。我认为可以避免 binary 源码的使用。或者修改代码，直接用二进制方式打开源文件，不要走 freopen 。

建议用额外的库实现额外的功能。不建议再增加和修改 skynet 核心功能以外的代码。

You may use macro `LUAMOD_API` instead. You can update your PR, and I will merge it.

cluster 的配置不一定是文件，可以是一个 table 。你要做的是按你的需求去生成这个 table 。 name 是一个字符串，你想拼出 "name[42]" 或 "name.42" 都是没问题的。

因为 cluster 没有任何底层设施，所以你完全可以不用 cluster 根据需求自己实现组网的需求。cluster 可以作为一个实现的参考，它本身也没有太多代码。 skynet 作为公共代码，我觉得不应该提供、规范太多细节。不然会有很大的维护负担。