liulilittle的博客

以下是参考的实现代码，IO_URING 操作必须要进行按页大小对齐（仅在O_DIRECT直接I/O下），不能是非对称的，一般大多数操作系统页大小为：4KB。批量读取、writev 批量简写。

通常不需要指定第二个source，这个一般用来匹配具体某一个网卡接口路由的，即source等于本机某个网卡的接口IP或网关。GetBestRoute 函数获取到目的IP的最佳匹配路由。第一个参数为：destination（目的IP）第二个参数为：source（源IP）

returnCode 为运行进程退出返回的错误代码，通常进程返回：0。filePath 为运行的EXE（可执行文件）路径。arguments 为运行使用的CLI命令行接口参数。runas 为是否以管理员身份运行。

这需要像 Visual C# 语言之中的检查类似，对于无效的 Double 双精度浮点数都应认为是 NaN。

支持：NDK、MAC-OSX、LINUX、Windows 等多个操作系统发行平台。

LINUX、MAC-OSX（苹果）、NDK（安卓）为判断是否为ROOT用户，Windows 判断是否为 Administrator 超级管理员身份运行。

支持：NDK、MAC-OSX、LINUX、Windows 等多个操作系统发行平台。

支持：C++11 及早前标准库版本，而无需使用：std::this_thread::get_id()。支持：NDK/ANDROID、Windows、Linux、MacOS X 等多个操作系统平台。

GNU编译器虽然支持 #pragma pack(push, 1) 来进行对齐，但在一些特殊的LINUX平台及特定的GNU编译器版本上支持是有问题的，即：我们预期对齐是19字节，但它仍旧是23个字节，但通过GNU编译器单独的 __attribute__((packed)) 特性，可以解决该问题。即，采用 GNU编译器的间距跨平台编译的，应首选采用GNU/GCC编译器特性，__attribute__((packed)) 来声明该结构体为1字节序列对齐。

这是源于：A/B可能会在发送到服务器时产生丢包，或因为网络波动（如TTL沿途跃点的路由）、OS内核事件排队等等，导致两个链接包发送到服务器先后顺序是不同的，在UDP之中乱序问题一直是不可避免地，回归TCP的本质协议实现，UDP存在的问题TCP协议本身也存在，只是大家基于逻辑链接开发，并不能从上层感知这种问题而已，但这并非是不存在。2、单一TCP链路，在应用程式保证有序的前提下，难以把产生的CPU的计算负载压力分摊到其它线程之中，这可能导致在宽频交换的高压状态，某一个CPU核心的负载压力过大。

2、Windows 平台可以通过 CreateProcess 函数来创建新的进程，在把自己结束退出就可以了，还有一个办法是比较暗黑的做法，就是通过替换进程的内存来实现替换进程，但容易被杀毒软件爆毒，就是 Windows 平台上的替换进程技术。1、Linux/OSX 上面重新运行程序，直接使用 execvp 函数就可以了，把main 函数传递来的 argv 二维数组（命令行参数）传进去就可以，注意不要在 fork 出来的子进程搞。源实现大概是这样的。

这样，可以确保我们在任何操作系统及编译器平台上面，编写的相同代码执行效果是一致性的，因为有些代码是通过二进制的算术溢出的来处理的，尤其是位运算对于数值的字节长度是非常敏感的，一旦字节数不同运行的预期结果就会合实际实现的不同，尤其是跨平台的应用程序开发，人们很难再所有的平台上面都能确保其运转无误，因为测试成本是非常昂贵的。相信有过多种平台、编译器的 C/C++ 程序开发的童鞋深有同感，在不同的 C/C++ 编译器及平台之中，INT、LONG的长度可能都是不一样的，这可能会带来编程及运行时上面的一些疑难问题。

例如：C/C++ 11、14、17、20、22 等，这是好事儿，兼容性很强，但缺点也很明显，使用的复杂度及安全风险性问题会高很多，所以协程架构需要一个 C/C++ 很有经验的人作为，IA基础设施架构师来负责承建工程并且为它提供运行时可靠性保证。当多个线程及协同程序工作时，并承担高负荷的计算及交换压力时，内存负载表现，当然受限于不同的应用场景，内存负载略有不同，但大多数应用程式并不需要多大的内存负载，如果内存占用过多，人们可以仔细思虑是否整体架构及实现存在问题。1、需要为每一个协同程序分配独立的栈空间。

该问题发生时，应用程序将无法被 KILL -9、系统无法回收进程资源，且若运行在 screen 之中，则 screen 无法被关闭，产生僵尸进程，持续耗费设备硬件及内存资源，直到设备系统被重启。并且鉴于，该问题并非是，必定重现的小问题，它复现需要程序稳定工作、且交换大量的数据吞吐量，才有一定的概率性复现，即：至少需要先跑 7*24 小时，所以定位它就变得很困难及费事。起初以为是应用程序本身的问题，把可能会导致该问题发生（deadlock）的地方，全部重新编写，但仍旧没有解决它。

那么，假设该设备只有两个核心，程式只应用到101%的能效，并且不能提高吞吐量，事实上，若令两个U核，同时为所有的链接，真正的多核并行提供能效，这必定可以提高其的能效宽频IO吞吐量，而非像如此一般因为U核负载瓶颈，迫使性能不能真正被发挥出来。缺点：某个子线程，在一定的场景之中，必然会发生算术负载积压的问题，根据操作系统内核调度的特性，发生算术负载积压时，某个#CPU核会承担非常繁重的事务，这并不能达到，人们所期望的多核并行计算，同时且合理利用多个#CPU核。形式：每次捕获链接，fork 一个子进程出来处理。

【代码】C/C++ 获取当前程序编译依赖的GLIBC版本 ON LINUX/GUN。

3、boost::asio >= 1_86_0 及以上版本，所有的 async_xxx、如：async_read、async_write 函数的事件回调函数，都不可以在返回值，否则编译警告。

多线程在最求能效得情况下， 也只能保证AP，而无法保证CAP，否则多线程将被退化为单线程，然而其能效甚至不如单线程处理，因为事件及临界区得同步将导致CPU上下文频繁得切换，也包括INT 2E/sysenter/sysleave 断入/断出内核态，所产生得能效负担。在分布式或多协程、多线程得系统之中，不可能存在三角都同时满足的情况，如果为了保证一致性，那么就需要降低系统能效，因为这涉及到同步问题。如果人们想要兼容性，那么就需要牺牲一些功能，因为很多功能在不同得平台上面，几乎没有办法被移植实现。

2、安装软件 GIT、GCC、CMAKE、G++、Golang:1.16 及以上版本。1、准备一个 Ubuntu/18.04 LTS 系统的设备。

【代码】Linux C/C++ 查看内核版本。

【代码】C/C++ MacOS X 添加/删除路由（内核API调用方式）

【代码】RC4 in C/C++ Impl。

【代码】IPv4 checksum in C/C++ Impl。

1.0.1.0/241.0.2.0/231.0.8.0/211.1.0.0/241.1.2.0/231.1.4.0/221.1.8.0/241.1.9.0/241.2.0.0/231.2.2.0/241.2.4.0/241.2.5.0/241.2.6.0/231.2.8.0/241.2.9.0/241.3.0.0/161.4.1.0/241.4.2.0/23。

MSDN：SetPriorityClass function (processthreadsapi.h) - Win32 apps | Microsoft Learn当人们调用 SetPriorityClass 函数并且将 “dwPriorityClass” 参数设置为：PROCESS_MODE_BACKGROUND_BEGIN 时。应用程序得工作集（Working Set）内存，开发人员必须控制在 32MiB，否则会导致大量得 “内存缺页异常”，因为操作系统会把多余得内存频繁得转储到 “PageSys”

在 Android 平台上，不建议大家在 C++ 上调用该函数解析DNS信息，但 C 语言是可行的，或 C/C++ 调用方层级不多且代码并不复杂，如调用方存在大量的 STL 字符串或容器计算，则不建议大家在安卓上使用它。getaddrinfo 是POSIX定义的通用函数，该函数可以在 Windows、MacOS X、Linux、Android 等平台正确编译且工作。这是原因，在这类的场景下，它可能导致程序运行时无意义崩溃，在非 Android 平台上面则无所谓。

另外在 __MUSL__ 之中，我们需要频闭对于 GUN/C/C++ 扩展函数库：#include 的使用，所以不要指望，可以通过该函数解释C符号。所以，我很讨厌某些装逼人，技术不咋地，这个瞧不起、那个瞧不起，boost 库那么好用，兼容性这块没得说，除了代码量确重了点，然而并不差，但这个可以花点时间剔一下不用的代码的。该宏在 GUN/LLVM C++ 之中使用 GLIBC 运行库CRT时，是默认被定义的，但在 __MUSL__ 之中缺省是没有定义的。

上述的代码，在绝大多数编译器及平台上面都可以确保流程跟我们预期的一致性，但仍旧不能保证在优化之后会像例二一般，出现问题，虽然这段代码的编写方式，比例子二在更多的编译器、及平台上面有保证，所以我们需要例子四。在C/C++ 之中，我们常常利用RAII机制，来处理某个临时块得初始、及利用编译器自动析构，但这可能存在一定的致命性风险，如果你没有遇到，只是你没有过多的进行了解，挨得毒打太小，导致的。在执行 std::shared_ptr 的析构函数，在很多编译器之中是这样，但在一些编译器之中，

在 Windows 与 Unix 平台上面得 C/C++ 之中，都标准提供了 access 函数得实现，只不过参数会有一些不同。鉴于 Windows 与 Unix 平台上面，对于 access 函数参数得宏值定义不同，所以人们需要定义一个内部枚举。其后，在通过定义得内部枚举，根据行为得不同实现具体得事务。

Unix 平台（Linux/Android/MacOS X）1.2、不通过追加到尾部字符命令。1.1、通过追加到尾部字符命令。2、通过 Lseek 函数。1、通过C语言文件函数库。

它主要是提取DNS数据包之中查询问题的信息，如：问题类型、问题类别、问题内容（域/IP），我们如果想要对于某个DNS数据包需要进行遥测的时，或者进行NS缓存生命周期管理，那么就需要类似这样的函数实现了。

关于 Windows 平台下面 C/C++ 通过WINAPI操作路由的实现，可以参考开源项目 openppp2 的实现。Windows 平台可以参考本人的这篇文章的实现，利用 Windows 路由WINAPI接口来实现。关于 Linux 平台下面 C/C++ 通过LIBC API操作系统路由的实现，可以参考下述的实现；三个平台通用的实现，可以参考 openvpn 的开源代码实现。

大体实现，缺省模拟双向各丢10%的情况，即折合在20%网络丢包率下工作。等等，感兴趣的童鞋，可以自行研究，这是个网络流控控制协议。4、SWS糊涂窗口综合征处理。10、指数平均加权退让。6、SACK选择确认。

用来操作，map、unordered_map、hash_map 等字典类型集合，用这个单纯是为了代码阅读起来更好一点。

为了保证 boost 库版本的代码兼容性，这是为了在多个平台上面跨平台编译的兼容性，所以我们通常需要去兼容打上这些补丁。

为什么不推荐 boost::asio::ip::address::from_string、boost::asio::ip::address::make_string 函数来把字符串转换为 ip 地址呢？这是因为有平台、编译器兼容性，在 android 平台上面，使用这两个函数会导致崩溃问题，在一些 clang 编译器上面也会导致崩溃问题。所以人们必须实现这两个函数。

A协同程序内部发起一个异步操作，并且 yield 让出CPU，但传入回调函数到异步操作内，异步操作失败，直接丢弃异步操作的上下文，而不驱动异步回调函数的调用，导致协同程序根本无法 resume，有非常多煞笔、智障、且偷懒，不是个人的东西，就很喜欢这么整，这种人是需要深恶痛绝的，即便是异步编程这样的下三滥行为都是不被允许的，试问：谁家会这么教育人这么干？这样的多核并行驱动架构，可以显著的提高整个应用系统的吞吐能力，至于多线程带来的复杂性，这并不可怕，合适的架构并不会导致这些致命性问题的产生。

PID=0，缺省为当前进程，但最好是获取当前进程ID传递进去，当然也可以选择其它进程的ID。

提供可变数组封装、可变类型数值/字符串获取等。

BSTR 字符串转 std::string 字符串。std::string 字符串转 BSTR字符串。