针对 当socket可写的时候【发送缓冲区没满】,会不停的触发socket可写事件 ,我们提出两种解决方案【面试可能考试】;
b)两种解决方案,来自网络,意义在于我们可以通过这种解决方案来指导我们写代码;
b.1)第一种最普遍的解决方案:
需要向socket写数据的时候把socket写事件通知加入到epoll中,等待可写事件,当可写事件来时操作系统会通知咱们;
此时咱们可以调用wirte/send函数发送数据,当发送数据完毕后,把socket的写事件通知从红黑树中移除;
缺点:即使发送很少的数据,也需要把事件通知加入到epoll,写完毕后,有需要把写事件通知从红黑树干掉,对效率有一定的影响【有一定的操作代价】
b.2)改进方案;
开始不把socket写事件通知加入到epoll,当我需要写数据的时候,直接调用write/send发送数据;
如果返回了EAGIN【发送缓冲区满了,需要等待可写事件才能继续往发送缓冲区里写数据】,此时,我再把写事件通知加入到epoll,
此时,就变成了在epoll驱动下写数据,全部数据发送完毕后,再把写事件通知从epoll中干掉;
优点:数据不多的时候,可以避免epoll的写事件的增加/删除,提高了程序的执行效率;
老师准备采用b.2)改进方案来指导咱们后续发送数据的代码;
一:发送数据指导思想
把要发送的数据放到一个队列中[msgSend],然后咱们专门创建一个线程[ServerSendQueueThread]来统一负责数据发送;
二:发送数据代码实战
(2.1)信号量:也是一种同步机制;他跟互斥量有什么不同呢/特殊?
互斥量:线程之间同步;
信号量:提供进程之间的同步,也能提供线程之间的同步;
《Unix网络编程 卷2—进程间通讯》第二版,第十章 清晰描述了信号量用法;
用之前调用sem_init()初始化一下;信号量的初始值 我们给了0【这个值0有大用】;
用完后用sem_destroy()释放信号量;
sem_wait():测试指定信号量的值,如果该值>0,那么将该值-1然后该函数立即返回;
如果该值 等于0,那么该线程将投入睡眠中,一直到该值>0,这个时候 那么将该值-1然后该函数立即返回;
semd_post():能够将指定信号量值+1,即便当前没有其他线程在等待该信号量值也没关系;
(2.2)数据发送线程 ServerSendQueueThread ********************
(2.3)可写通知到达后数据的继续发送
ngx_write_request_handler(); ************************
(2.4)发送数据的简单测试
发送缓冲区大概10-几10K,
如何把发送缓冲区撑满
(1)每次服务器给客户端发送65K左右的数据,发送到第20次才出现服务器的发送缓冲区满;这时客户端收了一个包(65K),
此时执行了 ngx_write_request_handler();
(2)我又发包,连续成功发送了16次,才又出现发送缓冲区满;我客户端再收包,结果连续收了16次包,服务器才又出现
ngx_write_request_handler()函数被成功执行,这表示客户端连续收了16次包,服务器的发送缓冲区才倒出地方来;
(3)此后,大概服务器能够连续发送16次才再出现发送缓冲区满,客户端连续收16次,服务器端才出现ngx_write_request_handler()被执行【服务器的发送缓冲区有地方】;
测试结论:
(1)ngx_write_request_handler()逻辑正确;能够通过此函数把剩余的未成功发送的数据发送出去;
(2)LT模式下,我们发送数据采用的 改进方案 是非常有效的,在很大程度上提高了效率;
(3) 发送缓冲区大概10-几10K,但是我们实际测试的时候,成功的发送出去了1000多k数据才报告发送缓冲区满;
当我们发送端调用send()发送数据时,操作系统底层已经把数据发送到了 该连接的接收端 的接收缓存,这个接收缓存大概有几百K,
千万不要认为发送缓冲区只有几十K,所以我们send()几十k就能把发送缓冲区填满;
(4)不管怎么说,主要对方不接收数据,发送方的发送缓冲区总有满的时候;
当发送缓冲满的时候,我们发送数据就会使用ngx_write_request_handler()来执行了,所以现在看起来,我们整个的服务器的发送数据的实现代码是正确的;
三:发送数据后续处理代码