数据没用的话可以当防身武器

怎么会扯了这么远呢, 怎么还能扯到什么系统完整性保护，这分明是故意增加障碍好不好啊。
保证系统可用是第一步的，尽量减少耦合性， 还有 fallsafe 原则。

当然直接去修改厂家的 rom 也是太闲了， 直接购买能刷 lineageos 等比较流行的开源 rom 的机器就是了

@LGA1150 这个很有必要推广开, 越来越多的路由器开始采用魔改的 openwrt 系统了

@zhouyut001 我是说你这个 nat 设备是 linux 系统的

@LGA1150
WAN INPUT 设成 ACCEPT 后对于到达本地的不可转发的 udp 数据包会返回一个 icmp 错误，而默认的时候是装作没听见
是这个区别么，stun 检测的时候哪个环节导致的这两种情况的差异呢。

这个文章也看了 https://blog.csdn.net/u011245325/article/details/9294229 没仔细看 stun 的源码， 还是不明白为什么会导致这个差异。

@lqf96 你说的这个人就是 @LGA1150
@p64381 同好奇
@zhouyut001 这个是 linux 的系统
@LGA1150 在使用 openwrt 后得到的是端口限制的类型 不是 Symmetric， 直接用 tplink 就是 full cone

@cwbsw Full Cone 最多只能 0xffff 个连接的
symmetric nat 可以根据 dst ip dst port src port 查找 nat 表 实际支持的多的多了。

@gnaggnoyil 能用 container_of offset_of 实现一堆代码复用我就比较满足了啊
@mashiro233 协程切换是用户态的，速度快很多， 但我还是没用这个东西，如大家所说反正都是事件驱动的。
但是有个特例是 linux 文件系统的 io，这个还是阻塞的，没有和 epoll 配合。 但是 freebsd 的 kqueue windows 的 iocp 都能配合文件系统 io 使用。

好奇是几个 T 的什么东西呢

@zhicheng 能写 VM OS 编译器肯定能十分钟写出链表来

@c3824363 linux 内核代码的模式可以在不用 C++的情况下也能写出清晰明了好维护易扩充易复用的代码，这就是我不用 C++的理由。

@Applenice 那个 list.h 大致看一眼就全明白了，直接用是因为这个快成圈子里的标准了。
rbtree 那个就复杂很多了， 没细看过它的代码，感觉自己没有那个水平也没那个必要去看，但是一直在用。
关键的是那个 container_of 的思想让我在用 C 编程上放飞了一下。

@Applenice 内核里面还有个好用的 rbtree

@killpigman 算上放水导致的稀释可能还赔了

@c3824363 本身 epoll IOCP kqueue 也提供了携带一个指针的方式来让你关联一个结构体来实现我说的第一种方式。

@current 我的意思是说如果不用协程，直接根据类似 epoll 的事件驱动， 然后写对应的事件处理函数，那么这样写起来就必然要用一个结构体来包含一个或多个 socket 和相关的上下文数据，这样就不是很直观了。为了简化和抽象出一个框架，还会用回调的方式，这就让初学者看起来就更不直观了。

但是如果用阻塞的简单方式编程呢， 那么这些结构体里面的上下文数据就可以展开成一些普通的变量了，然后配合阻塞的方式，能一眼从头看到尾，初学者也能一眼看明白了。 但这样只能用多进程多线程处理多连接，用于切换的损失比较大。

协程就是用用户态自己切换上下数据的栈，来同时实现高性能和编程的简单直观。

正常情况下我不用协程，直接用前面说到的第一种方式，例外是用 lua 的场景。 没有笔误，就是没有表达清楚。

加密 rar 改扩展名就能发送了

@wekw 协程的本质不就是用户态程序自己切换"栈"么, 目的不是为了简化同时处理多连接的编程么，弄的异常复杂了还有什么意思呢。

@wekw 协程是为了方便人类的思维习惯而搞出来的东西吧, 每个连接自己携带一堆上下文数据不是一样的么。 就是用起来不像阻塞编程那么直观，但习惯了还是一样的吧。