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

  • 相关阅读:
    swing之jtable的详细介绍
    JSplitPane类测试实例
    在桌面应用中使用JAVA DB[组图]
    java线程池主线程等待子线程执行完成后再继续处理后面工作
    Cannot load 64bit SWT libraries on 32bit JVM 解决方法
    Cannot load 64bit SWT libraries on 32bit JVM
    java程序的皮肤效果实现代码
    Java设置窗口大化时大小
    Java Swing 组件全演示
    Java 线程池详解
  • 原文地址:https://www.cnblogs.com/cppisnotbad/p/3244487.html
Copyright © 2011-2022 走看看