xindong/frontd

心动网络游戏通用网关

frontd's Issues

接受新连接失败，直接Fatal是不是不合适

 
for {
        conn, err := l.Accept()
        if err != nil {
            log.Fatal(err)
        }
        go handleConn(conn)
    }
接受新连接失败，直接Fatal是不是不合适，已经建立传输的连接会断掉。

协议设计的一些想法

目前的设计是初始化连接时用换行文本协议，如果初始化失败则回发二进制的错误码。

我在想，既然初始化已经用到文本协议了，何不连状态码返回也一起用文本协议，反正状态码也没几个字节。

还有一点是连接成功没有成功对应的状态码返回。

如果连接成功失败都有文本的状态码返回，就可以比较方便的用telnet做测试，手工发送一条连接初始化信息，在telnet可以直接看到服务端回发什么数据。

另外，是否需要在开头加个协议版本号，方便将来协议升级向下兼容不同版本的客户端？

关于pprof

线上项目经常会需要用到pprof监控项目，建议添加pprof相关的命令接口或者用go自带的net/http/pprof。

自己提供命令接口的好处是可以减少配置量少占用一个端口，用自带的net/http/pprof的好处是工具配套全，不用自己再手工到服务器上下载pprof数据。

之前都是自己造轮子，但新项目上我倾向于用net/http/pprof。

端口配置问题可以用+1的方式来省掉手工，比如frontd端口在1234，frontd的pprof接口就是1235。

关于OpenSSL这个库的设计问题

看了一下github.com/Luzifer/go-openssl这个库的代码，发现里面的接口设计不太合理，接收的参数使用string类型内部再转成[]byte使用，而调用者手头有[]byte时还得转成string给它，这样来回转换徒增数据拷贝次数。

建议把这个库的代码copy到项目里改改或者fork一个来改，参数统一用[]byte，顺便也减少第三方库依赖。

MaxOpenfile问题

frontd相对于后台服务器是作为客户端存在的，向后端服务器建立tunnel，单ip连接数应该受限于64k，代码中设置MaxOpenfile为1024 * 1024 * 1024有意义吗？ 实际项目应用中没有碰到类似问题吗？

这个和 nginx 反向代理的有啥区别吗？