segments的专栏

面对一个架构设计繁复的linux服务器端应用，难于维护的局面，如何破局？其中，性能总是不达标怎么办？

面对一个架构设计繁复的linux服务器端应用，难于维护的局面，如何破局？我想起当年大家讨论敏捷开发的事情。若干年后，尘埃落定，敏捷开发遗留下的最实用和重要的是：结对review和每次构建。

面对一个架构设计繁复的linux服务器端应用，难于维护的局面，如何破局？看看《unix编程艺术》一书里，unix哲学基础章节如何说的。1 模块原则：使用简洁的接口拼合简单的部件2 清晰原则: 清晰胜于机巧3 组合原则：设计时考虑拼接组合4 分离原则: 策略同机制分离，接口同引擎分离5 简洁原则：设计要简洁，复杂度能低则低6 吝啬原则: 除非确无它法，不要编写庞大的程序7 透明性原则：设计要可见，以便审查和调试8 健壮原则: 健壮源于透明与简洁9 表示原则: 把知识叠入数据以求逻辑质朴而

写下这个文章的时候，刚从一个复杂的linux服务端网络应用项目中脱出，除去身心的疲惫不堪后，不得不反思标题中的问题，如何破局？这样在下次面对相似问题时，可能就多几分幸存的几率。“最想知道我是在什么地方死的，这样我就可以避开死亡了。” 这个是查理芒格多次讲过的话。但是很多人被困难问题击败后，都没有找到自己是在哪儿失败的？如何破局？首先是找到在哪儿挂的和挂的原因。

摘自：https://www.cnblogs.com/embedded-linux/p/7468442.html对端正常close socket，或者进程退出（正常退出或崩溃），对端系统正常关闭这种情况下，协议栈会走正常的关闭状态转移，使用epoll的话，一般要判断如下几个情况 处理可读事件时，在循环read后，返回结果为0 处理可写事件时，write返回-1，errno为EPIPE EPOLLERR或EPOLLHUP或事件 对端非正常断开，比如服务器断电，网线被拔掉这种情况下，协

在Linux下的TCP通讯，如果能通过工具实时的获取某TCP通讯的RTT，就能比较清楚得知道当前网络TCP通讯的拥塞程度，在一定程度上对网络拥塞做出量化数据，记录历史日志。问题是，有什么工具或办法直接拿到RTT数据呢？------------------摘自某个被TCP通讯中的timeout搞得头痛的码农什么是TCP的RTT？这个还是网上搜索科普吧。这里将范围缩小，我们讨论的目标是如何对一个正在运行的socket（TCP）通讯应用，做一个RTT的Benchmark。如何测试硬件系统和操作系统本身带

前言开源项目libevent已经在业界广泛使用，甚至是一些对开源软件有着苛刻看法的大公司都在自己的项目里引入了libevent。好吧，libevent项目到底是什么鬼？简介

没有被SPI调试搞痛过，敢说自己调试过SPI通讯吗？分享一次调试SPI的经历，其中遇到的困难和问题，以及应对问题的方法，可能对读者有一定的参考意义。当然读完后，没有发现有价值的东西，还请求继续读下一篇........