fpcc的专栏

这个小故事耽误了不到两个小时，主要是原始网络库编译成功而自己的项目不能使误导了方向。但回过头来再看，发现国外做开发的人真得想得周到。只能说自己解决问题的想法还是不够严谨，也算是一次对自己的反思吧！

在实际的开发中，有时候儿需要两个设备的时钟同步，而且要求的精度相对较高。那么解决这种同步的方式有很多种，比较常见的就包括本文提到的IEEE1588标准协议。这个协议早期是在工业上应用的，后来才引入到了以太网中。在实际的开发场景中，多是在嵌入式中使用，毕竟一般也是硬件对时钟有很强的同步需求。而在更上层的软件上，一般底层做好时钟同步，而其本身只需要用就可以了。不过为了同步的快捷和方便，嵌入式中对同步往往不会是在以太网的全协议栈上进行即更多可能是在链路层等中直接进行时钟的同步（可能由硬件实现）。

这类技术如果不是说专门要搞这个行业，一般不用钻研进去多深。只要明白基本的技术流程，然后借助第三方库完成即可。这就是经常说的抓大放小，提纲挈领。

这种小问题，往往需要重复的造轮子。这个小总结就算给大家重复造轮子时的一个借鉴吧。

脚本用处真得很大，尤其在一些监控、测试的情况下，一个简单的小脚本就可以达到控制程序的目的。特别是粘连一些相关工具如Jenkins和部署时，可以极大的减少代码的工作量并迅速构建迅速部署。当然脚本的缺点也不少，最显著的就是不好调试，对一些复杂的函数和变量往往需要死记硬背。建议大家都要好好学习一下脚本相关的知识，这样在服务端开发中，会大提高工作效率。原来总以为脚本是运维的事儿，后来才发现大谬。好好学习，犹未晚尔！

学习理论知识十分的枯燥，特别对工作后的人，不论是从记忆力还是注意力，已经从单纯的学习转向了为了生活而打拼。此时对一些理论性的东西往往感到没有什么意义。但还是需要强调的是，计算机技术是一门非常强的理论和实践高度结合的技术学科。理论和实践缺一不可，新技术的突破往往是开发应用瓶颈的突破口，不需要到处再打补丁；同样，丰富的实践场景可以推动技术的完善和创新。思维不要僵化，要与时俱进。

eBPF的发展史，就是一部需求推进的发展史。所以说，技术不落地，发展的速度就会受限。反过来，强劲的落地需求，推动着技术不断的完善和快速发展。学习也是如此，如果只是为了学习新技术而学习，无法在实际工作中应用，那么技术学习了往往也会被忘记。而如果在实际的场景中应用到，那么对技术的理解会越来越深越来越通晓。这样，在后面的工作中会应用的如鱼得水。甚至有可能反过来，深入技术内部进行完善和修改。

在上文中介绍了XDP技术，XDP技术的基本原理已经明白，但有一个问题，一个技术如何落地，如何在实际中应用？这就需要有一个承载其的具体的形式。举一个例子，网络编程一般使用Socket方式，那么能不能够在这种方式里使用XDP技术呢？答案是肯定的。Linux在内核中提供了AF_XDP套接字编程，这就意味着，大部分的编程方式仍然可以以原来的套接字编程为主。这样的好处显而易见，对开发者和维护者来说，都是相对要容易理解和支持。AF_XDP类似于AF_NET（TCP/IP等）等一样，是一个协议族，大家有没有记得在TCP

XDP：eXpress Data Path，快速数据面，听名字是不是很高大上。其实它就是一个快速处理Rx数据包的数据面技术。为什么现在对数据处理如此敏感？原因非常简单，随着网络的不断覆盖社会的各个层面，海量的数据不断出现，而处理这些数据就要求一个字，快。无论是Linux亦或是Windows，它们都产生于早期的计算机系统，对快速的网络数据处理，大多天生就带有一些不足，这也导致了很多的问题。一般来说，操作系统的特点就是要有相当大的通用性，而这种通用性往往也是性能的瓶颈，这个瓶颈自然也包括网络数据通信。

时隔多年，在CMake工程中再次使用此工具，有些细节已经改变，安装环境也略有不同，所以重新总结安装步骤，以咨为记。

其实说得更浅显一些，所谓零拷贝更准确的说不是零次拷贝，是指尽可能的减少拷贝。在DPDK的系列文章中，这种操作被发挥的淋漓尽致。互联网的口号就是“不让中间商赚差价”，这个在现实上可能有一些逻辑上的BUG，但在内存操作上确实是非常用益。当然，万事万物不是说是绝对的，有的时候，抽象一下，加一层，如果能达到更好的效果，又不影响实际的使用的情况下，岂不更妙？千头万绪又回到始终坚持的原则，应用场景决定应用技术，实践是检验真理的标准。

不同的版本的DPDK可能源码会有些不同，请注意版本即可。重点是把DPDK的相关应用熟悉，在此基础上才能更好的对DPDK的框架有所了解。由应用到内部的实现，可能会更好的理解DPDK的设计理念和相关技术特点。

对于信号这种古老的应用，还是要理清其原理，在实际应用中根据场景来决定应用的情况。比如前面提到的在测试性能的场景下使用，有一两次问题也无所谓。而对于应用场景非常高的情况下，尽量还是谨慎应用。还是那句话，没有最好，只有最合适。

这里没有更细节展开谈IO模型和同步异步以及阻塞非阻塞的问题，这些基础的问题，不明白的需要去查阅相关资料。这篇文章只是一个开始，以后有机会的话，会将整个网络开发进行整体的分析说明和具体应用。技术的进步一定是向前发展的，开发者们一定睁开眼睛，瞭望世界，不要固守一隅，夜郎自大。

写守护进程使用哪种方式，看实际情况来定。永远记住一点，简单即真理。这个简单不只是技术简单，如果有熟练的使用过某种技术的开发者来说，那也是一种实现上的简单。复杂的技术和方法，一定会慢慢被简化，这是一种大趋势。

其实从上面分析来看，不管采用何种手段，目的只有一个，流水线作业要尽量保证流水不停不乱。这样，就可以高效率的生产和处理数据。这种数据处理型的软件框架，最重视的就是这些，只要数据保持了流水按照意图前进，就达到了设计目的。毕竟，只要有了外在的干预，这个干预时间对CPU来说就是一个超长的时间周期，那么效率已经就不再乎了。而在没有干预的情况下，就必须保证数据最大的流水。比如下载网络数据，在线观看视频，在线视频会议等等。

总之，应用是根本。有啥不清楚的多翻翻官网的手册，其实很多人不是没听说过某些命令，主要是经验不足导致无法组合的使用某些命令来完成一些具体的工作。工具就是这样，不像技术需要思考和反复验证。工具就看你用得熟悉不熟悉，用得时间长了，自然就熟悉了，这和开车没有什么大的区别。

在新的C++标准下，提供了很多新的锁，比如scoped_lock、shared_lock（对应的互斥体： timed_mutex、recursive_mutex、recursive_timed_mutex、shared_mutex、shared_timed_mutex）。还是要好好的看一看相关的锁的应用和跨进程中的使用的问题，没有实践就没有发言权。

在软件安装上，原来用apt安装相当方便、顺捷，也没遇到过什么大的问题，一般来说只要源给力，软件安装问题都不大，顶大自己手动下一个so来放到指定位置再设置下环境变量就足够了。可这几天安装编译一个开源软件就遇到了这种糟心的事儿，软件库安装成功了，结果和原来的软件库不匹配，总是有各种小问题，后来发现后才通过上述的方法给搞定。说白了，还是用得少。

对Linux的内存进行一个整体的介绍，为后面的分析打基础。

对缓冲区溢出做一个全面的分析

一、简介提到这个eBPF,就不得不提到BPF（Berkeley Packet Filter），它是一个用于过滤filter网络报文packet的架构。它是tcpdump 或 wireshark 甚至网络监控基础构件。它始于1992 发行在 USENIX conference 上的一篇论文：The BSD Packet Filter: A New Architecture for User-level Packet Capture。最初 BPF 是实现于 BSD 系统之上的，所以论文中称做“BSD Pack

Linux下的库相关工具和命令一、相关工具集在Linux的实际开发中，与库相关的命令工具有很多，这些工具在前面也介绍了一部分，现在做一个相对全面的介绍，掌握了这些命令工具，会在实际开发中大大减少解决问题的思路，提高开发的效率。在查找和定位问题时，起到事半功倍的效果。二、查看和分析工具1、file这个命令可以用来查看几乎所有类型的文件的详细信息file[-bchikLnNprsvz][-fnamefile][-Fseparator][-mmagicfiles...

一、动态库和静态库动态库和静态库各自有自己的优势，动态库可以减小应用程序的体积，动态加载，特别是共享库还节省内存，静态库加载快执行速度也稍微快一些，但相对来说就是可执行文件的体积大，修改后需要重新编译。说回来还是空间时间效率等的平衡。对第三方开放的重要的库，动态库居多，一来升级方便，再提供一个新库即可；如果提供一个框架库，就需要静态库或者说又提供静态库同时提供动态库，比如常见的C和C++的库，都提供了静态库同时也提供了动态库。不过一般在编译时（没有强制指定），默认都是链接的动态库，如果没有链接到动态库

一、静态库动态库学习完成后，要学习静态库了。其实，静态库的出现要比动态库要早，毕竟静态库相对动态库来说，从重用的角度来看，可以最先被设计人员想到，早期的静态库，其实就是多个编译单元的简单组合，它完全可以像普通的拼插玩具一样直接拼插到别的软件中，而不需要这个依赖那个依赖。换句话说，静态库是一个完整的软件模块的描述和运行的集合。既然是完整的，就会有一个现象，那么静态库是可逆向的，或者说，静态库是一系列目标文件的集合的文件。静态库和动态库的区别在于：1、静态库是完整的模块，可执行文件直接加载即可使...

一、Socket并发的配置在Socket并发访问中，五元组（源IP，目的IP，协议号，源端口，目的端口）的存在，使得其的可变化比较大，但其中大多数应用的场景可以抽象到一个具体的机器中来，在这一个具体的机器的配置中，引申出未来集群和分布式的配置管理。在一个具体应用中，一般来说的是一个单机，IP是固定的，但是端口是可以动态扩展的（0~65536,但是其中有不少被默认占用了），也就是说，作为一个单机，只考虑简单的变化情况，那么只有IP和端口两个作为组合的条件。如果有写过实际程序的，可以发现在客户端，一般就是自动

一、源码引入前两篇从应用分析到了库，本篇到内核中看看，futex到底何方神圣？（Linux3.1.1）先看一下futex.c和futex.h（kennel/futex.c linux/futex.h）:/** * struct futex_q - The hashed futex queue entry, one per waiting task * @list: priori...

在前方中提到过，经常使用的几个线程（进程）同步机制，其实都是调用futex来实现的，下面就从glibc2.8中把源码找出来对一下，看看到底是不是确实是如此，同时，对代码进行一些简单的分析。 每个细节的实现其实都可以展开来讲成独立的一篇，这里只是介绍同步机制的来龙去脉和实现，就不再对具体的细节进行展开，回头如果有时间，再对具体的每个技术进行专门的分析。 一、信号灯的实现int __n...

futex同步机制分析之一应用一、多线程（进程）的同步机制c++编程中最难的部分有哪些，估计绝大多数人都会首先提出来是多线程（进程）编程。为什么多线程编程难呢？一个主要的原因就是多线程的同步。在多线程同步中，（Linux平台Posix NPTL）中主要有三个同步手段：Semaphore（信号灯）、Mutex（互斥体）和Condition Variables（条件变量）。在c++11的标准中，同...

定时器timerfd的总结 以前总结过timerfd的用法，但还是总结的不详细，有些代码和理解仍然是有偏差，今天在看区块链的一些东西时发现了这个的用法，所以重新再整理一下，也算是对这个定时器的一个阶段性的收尾。这里首先对原来的一个问题进行一下详细的说明，即设置超时时间是需要调用clock_gettime获取当前时间，如果是绝对定时器，那么需要获取CLOCK_REALTIME，在加上要超时的