atsf4g-co的进化:协程框架v2、对象路由系统和一些其他细节优化
前言
年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多,一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱,仅当作一个参照和小计吧。
年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多,一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱,仅当作一个参照和小计吧。
这两天在做服务器框架的C的接口导出和C#的接入。之所以要做这么个东西是因为之前的服务器框架(atsf4g-co)已经完成了通信层面和基本设计模式的细节部分,而且基本算是最大化性能了吧。但是现在的项目的战斗引擎是从以前Unity游戏上抽象而来的,全部由C#编写。再加上最近再考虑接入实时战斗,这样就不能像之前一样用一个简单的通信方式了,必须使用一个高效并且实时性更高通信机制。需要能够处理好比较高的集中式的组播和容灾的通信方式。于是就有了把之前的C++的框架抽离出API来驱动逻辑的想法。这样也比较容易地兼顾开发成本和性能之间地权衡。
那么抽离出框架地目的是抽象出应用底层,这个刚好是atapp做的事,而且atapp的层面对外暴露的接口数量也比较少,使用比较简单,所以索性就直接对它下手了。
让后第一步是把atapp需要使用的基本接口抽离出纯C的导出API。之所以要导出成纯C是因为,不同系统环境和编译器环境在C++层符号规则、入栈出栈顺序、内存布局、对其规则等等都不一样。这种情况要做跨平台就很是困难,然而这些在纯C的ISO里都是有明确规范的。所以最简单的方式就是导出到纯C,然后其他语言导入接口。这里的其他语言目前就只有C#,但是纯C接口的话如果想导出到lua或者其他语言的接口也不困难。
这里导出的时候有一点点小细节,那就是在Linux上的c api是默认导出的,但是在Windows里是默认不导出的,然后再加上不同编译器的导出用法不一样,所以第一步当然是统一导出标记。最终就是下面这一段
近期仍然在搭建完整的游戏服务器架构。基于atsf4g(asynchronously-tree server framework fo game)的完整解决方案终于接近完成。基本框架之前其实已经做完了,但是之前解决的只是基本的框架层代码,不包含任何特定的交互模型、协议模型、配置服务等等。这回就整理了一个只包含登入登出逻辑的完整工程,另外优化了一些小细节和周边工具的支持。