1.TCP是流传输，所以本质上不该称之为粘包，发送者和接收者都是自顾自的，要一段一段发得选UDP
现象是，你发出3个2048字节的包，发送时会被优化成4096/2048，或者跟之前的包合并，但是取出时却很随意，除了空载时的首个包，其他有可能拆成1-4096大小若干个包
2.“粘包”和“分包”很头疼，但是只要抓住第一个包，问题就解决了一大半
幸运的是，TCP发出的包不是乱序的，这有点像你按顺序写出字节集一样，只要你抓住头部的定义，就能轻而易举解构数据
为此，发送时，首个包要跟前一段数据流有时间间隔，好让之前的Recv操作完成(当然，条件允许可以Recv完成后反馈，发送端收到反馈消息再继续下一波)
3.定义协议结构，各有各的办法，以下代码仅作参考
.版本 2 pocket ＝ 取空白字节集 (#pk_size) DataAddr ＝ 取变量指针 (pocket) ＋ 8 pk_sign ＝ 取字节集数据 (到字节集 (“P_KT”), #整数型, ) 写数值ptr (DataAddr, #pk_sign, pk_sign) 写数值ptr (DataAddr, #pk_crch, CRC32all) 写数值ptr (DataAddr, #pk_crc32, CRC32all) 写数值ptr (DataAddr, #pk_SN, 集_SN) 写数值ptr (DataAddr, #pk_remain, size) CRC32pk ＝ CRC32_PTR (DataAddr, #pk_size) 写数值ptr (DataAddr, #pk_crch, CRC32pk)
4.使用哈希表存储分包数据
我认为哈希表存储的方式是线程安全的，客户句柄是唯一的，一个客户甚至分不到一条线程，该句柄对应的数据地址是唯一的，所以不会出现两条线程同时操作一个内存地址的情形
当然，出现碰撞时，插入链表这个操作不是线程安全的，这个以后优化
5.星光极速模块我只稍微改了一下，把原先字节集操作改成指针操作
6.没有选择HP-socket的原因是太庞大了，用来做服务端可以，但是如果作为客户端即使是静态库，编译之后也很大
7.目前涉分包组包的代码不多，其他的运用过程中不断改进
关于哈希表的部分，我专门开了个帖子
https://bbs.125.la/forum.php?mod=viewthread&tid=14659403
