高效的UDPIOCP完成端口——啥叫做高效？？

Posted 2020-11-19 gamedelphi

    这段时间，可以说，简直吐血，开发两套完成端口控件，TCPIOCP和UDPIOCP，网上有现成的代码，唉，没有！真正没有水分的，确实没有。

至于UDPIOCP更别提。

    虽然测试的代码比比皆是。其实啊，你要写一个成型的UDP完成端口，这个难度怎生是一个惨字可以形容？

    于是乎，我一向的习惯是，不管做啥，首先会通过网络搜集各种资料信息，等到大脑有了基本印象，然后付诸行动。

    咱是一个强迫症类型的人，于是就是各种累！

   搜啊搜啊，于是乎，脑子更加混乱了。看看——各种论调，几乎都是围绕如何创建一个类TCP类型的UDP系统。各种创建可靠传输的UDP服务器。

   脑子发胀吧，甚至有人喷，UDP服务器真是高效？？当然了，如果是创建哪种链接类型（仿TCP）的UDP服务器，不管你咋弄，效率未必比TCP来得高效。

   昨晚，头脑理了一下，突然发现一个杯具的问题——

   好，咱点击一下UDP客户端，服务端没有启动的情况下，大家会发现一个最有趣的现象就是，客户端自己在哪儿不断地发送信息包，发啊发啊发啊...........................

  是不是挺过瘾的？

   这其实就是UDP它本身的特性：

   不需要链接，有需求，直接发包，没有需求，不占用系统资源 。

    再来看看UDP服务端：

    有信息发送过来，那么就接收，没有就等待。

    在此之前，咱维护一个链接客户端对象管理池。在某个时候，咱把这个客户端对象踢出去，但是在下一刻，这个被踢掉的客户端发送信息过来了，于是乎，服务端继续把这个客户端当作新的链接对象进行接收数据。也就是说，服务端完全不需要也很难去分辨这个客户端是不是被踢掉的客户端。

   也就是说，服务端的作用仅仅也仅仅响应消息的接收和发送，它不需要固定的链接。

    这就是UDP这种协议本身的特性。

    对，其实啊，很多人都走偏了。非要搞一个高仿的类TCP的UDP出来，其实都没有静下心来看看UDP其本身的特性。

    回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP.........................................

    哈，就那样，所有的问题，一下子完全清晰了起来，看，所有问题完全解决了。

    各种超时重传，服务端为什么要重传？超过一定时限，释放客户端对象（没有真正释放，只是重置一下各参数），纳入空闲管理——这些不多说，说太多了。

    对吧，服务端为什么要重传？？为什么呢？

    作为数据需求的发送者 ，客户端难道自己不做超时检测，在一定时间内，没有需要的消息到达，难道不重发需求？这是它本来的定位职责。

    一旦客户端退出，那么退出就退出吧，服务端还要管你这个啊？不是笑话？

    说到这里，其实应用层要做的不多，也不复杂了。

    数据包序列发送，客户端返回包头序列号，这中间都有可能会发生掉包情况，就看两者的对比机制。

    剩下来都是处理这方面的逻辑，方法多种，只要能够保证数据包能够完整地接收就行，不必啥可靠不可靠，只要信息最终能够到达。

    当你扔掉那些沉重 的负担，你会发现，UDP就是那么牛逼，UDPIOCP完成端口就是那么牛逼！

 

   最后，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP，回归UDP.........................................