关于网络编程的问题，

sjinny

既然调用send的时候也只是把应用程序里的数据复制到操作系统那排队发送，那么是否意味着应用程序这里不用实现一个等待发送数据的队列？
如果把操作系统的那段buf设置得足够大，那么大多数时候send都不会阻塞，都能把数据完全复制过去，这样应用程序就不需要再实现一层等待队列了岂不是很好？
[em24] [em24]

tarkey

当你往系统缓冲里拷贝的速度大于系统发送速度的话，总会溢出的，一旦溢出，发送的内容就丢失，而在上层做管理的话，可以避免这种信息丢失的情况。

sjinny

问题是即使是自己有一层buf，当这个buf满了之后怎么办？

sjinny

小小顶一下……

tarkey

概念性错误。
epoll或者select的话，有一个叫epoll_out/fd_write的东西，把你的socket放到这个队列里，当操作系统缓冲满了，并再次可以使用的时候，这个东西就会触发。

主要的思想是通过这个机制配合上层的buffer来实现，一般的做法是上层有一个buffer，当buffer快满的时候象应用层抛warning，然后根据warning做一些处理，把一些频繁需要发送的消息比如说位置信息之类的发送频率降低。诸如此类的解决方法。

sjinny

晕……每一种数据包都有其自己的作用，减小频率会不会带来很大问题……

我希望在上层buf满了之后，就把要发送的数据放到一个队列里……可这样就要多一次内存拷贝，因为本来可以直接把数据写到buf上，现在要先new一块内存然后把指针放到队列里……

其实即使在上层设置buf，当buf满的时候还是要减小发送的信息量，那么如果可以设置操作系统里的buf，把它设置得很大，并且在buf快满的时候减小要发送的信息量，这样是否就不需要在上次设置buf了？

very9660

所谓缓冲, 只能解决瞬间发送频率较大的情况, 而不能解决网络吞吐量. 所以, 如果你的缓冲区老是不够的话, 那么是不是考虑下增加硬件资源或者是对你的网络需求进行优化?

sjinny

要这么说，buf不够就算是比较严重的运行时错误喽？对于buf不够的连接是否可以认为客户端的网络线路不足以与服务器正常通信？

sjinny

再小小顶一下……

tarkey

对，属于严重错误，可以写入日志或者采取其他措施进行处理。