谁有例子 about kcp HOT 13 OPEN

@ranxu123 看看我的xkcptun项目，c写的，个人认为比较简单易懂
https://github.com/liudf0716/xkcptun

from kcp.

@liudf0716
good star了，终于有了c语言版本了，兼容Kcptun么？

from kcp.

@jonwinters 暂时不兼容，后期努力兼容。
欢迎一起来搞。

from kcp.

本来就是点对点使用的，有必要搞兼容吗？

from kcp.

@gaocuo 兼容的话，可以减少服务器部署的工作

from kcp.

为了自己省2分钟，要作者开发30小时，果然都是领导

from kcp.

@gaocuo
开源代码 看作者意愿，没有人能强制作者开发，你这语气，在github上 是要搞事情啊

from kcp.

我只是讨论需求合理性而已

from kcp.

@jonwinters @gaocuo 2位不要吵，和气，和气。。。。。:-)
感谢2位的关注和支持，我这边尽力去支持 @xtaci 大神的kcptun，不过c开发，大家都知道，比较费劲，估计要等一整了。

from kcp.

@gaocuo @liudf0716
个人观点不一样吧，需求没有合理不合理，只有需要不需要，
开源软件作者本身并没有义务去支援每一个人的需求，本身就是一个兴趣爱好而已，
我个人只是提个想法，并没有指着 作者的鼻子说 你不兼容某某 就不厚道 怎么 怎么的
我个人也是十分反对 那种站在道德高地上 要求作者这样那样的人

from kcp.

@jonwinters 对业界主流的兼容有利于项目的发展，这点考虑没错。

from kcp.

kcptun本身不是什么主流协议，而且从使用场景来看也极少用于对不确定人群的开放式服务，而且两端统一至少出了问题不需要同时对两个不同开发环境的程序排错，所以与其花精力在兼容上，不如花更多的精力在提高低cpu处理能力设备上的性能更加有意义，当然，这只是个人的建议。

from kcp.

@gaocuo 是的，这也是一种考虑方向。不过目前kcptun在服务器端的优势还是比较明显的，我当时弄xkcptun也是没办法，想在路由器上搞还得靠c。顺便吐个槽，c就是个迟早要完蛋的语言:D

from kcp.