# 3.x 版本变化

3.x版本是tarscpp在底层, 尤其是网络层做的一次重大版本升级, 重点支持了以下特性:

* 框架中网络层, 统一使用: TC\_Transceiver, TC\_Transceiver接口层面使用回调机制且默认支持ssl, 和tc\_epoller配合, 可以快速开发任何网络模型
* 协程处理提炼到公共类中, 可以参考文件: tc\_coroutine.h
* tc\_epoller完善接口, 网络和协程调度都通过tc\_epoller统一调度
* 服务模型变更为4四种模型
* tc\_http\_async支持了ssl
* 支持了无损发布

## 网络层说明

* TC\_Transceiver: 3.x版本在网络层做了完整的统一, 客户端和服务端的网络收发都通过统一的类处理了: TC\_Transceiver, 具体可以参考TC\_Transceiver的头文件说明
* TC\_Epoller: 完善了TC\_Epoller的处理机制, 说明如下:

> - TC\_Epoller本身继承于TC\_TimerBase, 因此它本身也是一个定时器, 但是定时任务的执行都在epoller的loop循环中
> - TC\_Epoller事件回调改成了注册监听回调机制, 通过子类EpollInfo类来注册事件的回调
> - 协程调度底层也是通过TC\_Epoller来实现, 这样保证了协程/网络能统一调度, 这个是3.x版本最大的设计变更!!!

## 协程说明

* 协程类统一提炼到公共库中(tc\_coroutine.h), 代码中涉及到协程的类主要以下几个:

> - TC\_CoroutineInfo, 协程信息类, 正常情况下业务代码不需要感知该对象
>
> - TC\_Coroutine, 协程类, 继承于线程类(TC\_Thread), 用来给业务快速使用协程, 这个类主要在一个线程中启动一批协程
>
> - TC\_CoroutineScheduler, 协程调度器类, 负责管理和调度协程, 本质上就是管理和调度TC\_CoroutineInfo
>
> > * 如果希望自己创建和调度协程, 需要重点理解TC\_CoroutineScheduler
> > * 每个线程都有唯一的TC\_CoroutineScheduler, 可以通过: TC\_CoroutineScheduler::create/scheduler获取掉调度器, 从而自己控制协程创建等逻辑
>
> * TC\_Thread, 线程类增加了协程的支持
>
> > - 使用它的startCoroutine方法启动以后, TC\_Thread::run则在协程运行
> > - 可以run中使用TC\_CoroutineScheduler来自己实现协程的创建等逻辑
>
> * TC\_CoroutineQueue, 用于跨线程的协程的数据交互, 队列没有数据时, 协程会阻塞在epoller上, 当有网络事件或者其他协程调度时会被唤醒处理其他事件!

## 服务模型说明

由于框架底层支持了协程, 因此服务模型也做了变更, 支持更多的服务模型, 目的是充分利用协程, 同时协程模型的优点时能降低延时. 四种服务模型说明如下:

* NET\_THREAD\_QUEUE\_HANDLES\_THREAD 独立网路线程 + 独立handle线程: 网络线程负责收发包, 通过队列唤醒handle线程中处理, 这个和老版本是一样的服务模型
* NET\_THREAD\_QUEUE\_HANDLES\_CO 独立网路线程 + 独立handle线程: 网络线程负责收发包, 通过队列唤醒handle线程中处理, handle线程中启动协程处理, 这个模型和老版本中启用协程后的模型相同
* NET\_THREAD\_MERGE\_HANDLES\_THREAD 合并网路线程 + handle线程(线程个数以业务线程配置为准, 网络线程配置无效): 连接分配到不同线程中处理(如果是UDP, 则网络线程竞争接收包), 这种模式下延时最小, 相当于每个包的收发以及业务处理都在一个线程中
* NET\_THREAD\_MERGE\_HANDLES\_CO 合并网路线程 + handle线程(线程个数以处理线程配置为准, 网络线程配置无效): 连接分配到不同线程中处理(如果是UDP, 则网络线程竞争接收包), 每个包会启动协程来处理

## 关于协程网络的混合调度问题

3.x版本一个重大的改进就是将协程的调度阻塞在epoller上, 通过唤醒epoller来完成协程的调度, 这个逻辑和网络层的事件唤醒保持了一致, 这样做得好处是网络收发等事件可以和协程事件混合在一起调度.

这样最直接的影响是: 客户端网络线程可以和服务端的处理线程混合在同一个线程中处理, 在3.x的rpc调用过程中, 如果服务模型是: NET\_THREAD\_QUEUE\_HANDLES\_CO or NET\_THREAD\_MERGE\_HANDLES\_CO情况下, 服务端收到网络请求后, 发起rpc到rpc回调, 都在同一个服务端的逻辑线程中处理的, 从而大幅度减小了线程切换, 降低了rpc的延时!


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tarscloud.gitbook.io/tarsdocs/tarscpp/tars-3.x-update.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.