zoukankan      html  css  js  c++  java
  • 高效的网络读写Buffer

      在做服务端开发的时候,对于来自客户端的请求以及返回客户端的应答都需要使用一段内存来缓冲数据,传统做法就是定长缓冲区,像这样:

      char readbuf[4096];
      char writebuf[4096];

      在你确定单个请求极限大小的情况下, 上面的定义也并不合理, 比如网络状况极差的情况下, writebuf的容量可能无法容纳待送出的应答, 这种情况只能无奈的断掉用户连接, 这并不合理.

      于是, 一个改进的方法:

    char *readbuf;
    char *writebuf;

      当缓冲区满, 我们通过realloc扩容, 保证总是能装得下数据, 上面的问题算是解决了.

       

      然而, 将缓冲区应用到网络开发的数据收发中, 我们不得不面临3个实际问题:

      1, 希望recv的数据直接写入readbuf末尾, 而不是先recv到临时缓冲, 再memcpy到readbuf末尾, 这样太低效. 所以我们需要预先为readbuf的末尾留出足够的空间.

      2, 用户解析readbuf头部的一段数据并处理完成后, 我们需要将剩余部分的数据memmove到readbuf头部,  尽量在readbuf末尾预留出足够的空间给接下来recv使用.

      2, 当writebuf的头部一段数据被send发出后, 我们不得不memmove将剩余数据向writebuf头部挪动, 以便其他数据append到writebuf尾部时有足够空间.

      

      这样来看, 似乎我们面临着极为频繁的memmove内存挪动, 这对非常消耗CPU的操作, 而这3个问题正是要优化的地方, 优化思路非常简单.

    www.settledown.cn

  • 相关阅读:
    rsync的man手册(未完成)
    rsync基础
    命令:mktemp
    命令:install
    [Abp vNext 源码分析]
    异常吞噬问题一则
    使用 Polly 实现复杂策略(超时重试)
    在 DotNetty 中实现同步请求
    使用 C# 实现 CJ-T188 水表协议和 DL-T645 电表协议的解析与编码
    DevExpress 使用 GridControl 时,数据源无法立即更新的问题
  • 原文地址:https://www.cnblogs.com/cppisnotbad/p/3244487.html
Copyright © 2011-2022 走看看