UDP协议

Posted by & filed under Uncategorized.

  UDP数据报长度 数据报的长度是指包括报头和数据部分在内的总字节数。因为报头的长度是固定的,所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说,包含报头在内的数据报的最大长度为65535字节。不过,一些实际应用往往会限制数据报的大小,有时会降低到8192字节。 UDP协议为面向报文的协议,发送方的UDP对应用程序交付下来的报文,添加首部后向下交付给IP层,不拆分也不合并,保留报文的边界,因此应用程序需要选择合适的报文大小。 UDP报文长度选择 FastSendDatagramThreshold:注册表中的一项 Windows Server Read more […]

MSS与tcp分片

Posted by & filed under Uncategorized.

  1        最大分段大小(MSS) MSS是TCP数据包每次能够传输的最大数据分段, 是TCP协议里面的一个概念。 为了达到最佳的传输效能,TCP协议在建立连接的时候通常要协商双方的MSS值,这个值TCP协议在实现的时候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以一般MSS值1460。 通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。 MSS 是TCP选项中最经常出现,也是最早出现的选项。MSS选项占4byte。MSS是每一个TCP报文段中数据字段的最大长度,注意:只是数据部分的字段,不包括TCP的头部。TCP在三次握手中,每一方都会通告其期望收到的MSS(MSS只出现在SYN数据包中)如果一方不接受另一方的MSS值则定位默认值536byte。 MSS值太小或太大都是不合适。太小,例如MSS值只有1byte,那么为了传输这1byte数据,至少要消耗20字节IP头部+20字节TCP头部=40byte,这还不包括其二层头部所需要的开销,显然这种数据传输效率是很低的。MSS过大,导致数据包可以封装很大,那么在IP传输中分片的可能性就会增大,接受方在处理分片包所消耗的资源和处理时间都会增大,如果分片在传输中还发生了重传,那么其网络开销也会增大。因此合理的MSS是至关重要的。MSS的合理值应为保证数据包不分片的最大值。对于以太网MSS可以达到1460byte.   TCP协议是面向连接的协议,对于TCP协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些TCP应用对分片有要求—不能分片(DF)。TCP也不会造成分片,原因是TCP自身支持分段: Read more […]

MTU与IP分片

Posted by & filed under Uncategorized.

  1        最大传输单元(MTU) 最大传输单元(Maximum Transmission Unit,MTU)是指一种通信协议的某一层上面所能通过的最大数据报大小(以字节为单位)。最大传输单元这个参数通常与通信接口有关(网络接口卡、串口等)。不同类型的物理网对一个物理帧可传送的数据量规定不同的上界。例如,以太网的MTU是1500。 在因特网协议中,一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所经过“路径”上的所有IP跳的最大传输单元的最小值。或者从另外一个角度来看,就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。 因特网协议允许IP分片,这样就可以将数据报包分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在 Read more […]

(转)深度探索C语言函数可变长参数

Posted by & filed under Uncategorized.

  一、基础部分 1.1 什么是可变长参数 可变长参数:顾名思义,就是函数的参数长度(数量)是可变的。比如 C 语言的 printf 系列的(格式化输入输出等)函数,都是参数可变的。下面是 printf 函数的声明: int printf ( const char * format, … ); 可变参数函数声明方式都是类似的。 1.2 如何实现 C语言可变参数通过三个宏(va_start、va_end、va_arg)和一个类型(va_list)实现的, void va_start ( va_list ap, paramN ); 参数: ap: 可变参数列表地址 paramN: 确定的参数 功能:初始化可变参数列表(把函数在 paramN 之后的参数地址放到 ap 中)。 void va_end ( va_list ap ); 功能:关闭初始化列表(将 ap 置空)。 type Read more […]

(转) 别再让C++头文件中出现“using namespace xxx;”

Posted by & filed under Uncategorized.

  在这里,我毫不回避地说了这句话: 引用 我再也不想在任何头文件中看到“using namespace xxx;”了 作为一个开发者/团队领导者,我经常会去招聘新的项目成员,有时候也帮助其他组的人来面试应聘者。作为应聘流程之一,我经常要求应聘者写一些代码,因此我检查过相当多的代码。在最近提交的C++代码中,我注意到一个趋势,在任何头文件中,我总是能看到以下代码: C++代码       using namespace std; 如果我用我们的代码检查系统(在实践中我十分推荐这个系统)来检验代码,以上那行代码经常会跟着一句评论“Timo不会这样写的”。他们说得很对,我确实不会这么写。 那么,为什么我说服了很多C++教材(也许并不是什么好事),让他们认为使用上面那段代码是非常坏的方式? 让我们先来看看上面那段代码做了什么。总的来说,它把命名空间“std”以内的所有内容(或者其他由作者用using调用命名空间)无一例外的引入了目前的命名空间中。请注意我说的“所有内容”,并不是一两个你想用的类\类型\模板。在一段代码的开头引入命名空间的原因则是加强程序模块化,和减少命名冲突。大体上,它允许你可以写类似下面的那段代码,并且保证编译器可以选择正确的实现: C++代码

现在,假定我们正在尝试减少代码输入,并且在以上代码中使用using声明(或者更糟糕的,两个命名空间都声明了),按照如下代码来实现: C++代码

  如果这段代码的作者很幸运的话,编译器会选择vector的正确实现,或者至少在最初的阶段会这么做。但是过了一段时间,你会碰到一些很奇怪的编译器错误。幸运的话,你能找到这些错误的原因——我曾经遇到过类似问题,我花费了好几天才能找到这类问题的原因。该死,它们会浪费你很多的时间,仅仅因为你为了想少打5个字符的代码。 并且,如果你把using声明用在了头文件中,你会让这类问题更加恶化,因为命名冲突问题早晚都会在一个调用关系非常非常远的模块中神不知鬼不觉的出现,而你可能需要查三层调用才可以找到原因所在,一个头文件包含了另一个直接使用using声明的头文件可以导致命名空间被立刻污染掉,任何一个使用命名空间的文件如果使用了std命名空间的内容,都会导致这类问题。 那么,为什么你能在很多教科书中看到它们使用using Read more […]

(转)C++处理异常 try,catch,throw

Posted by & filed under Uncategorized.

  异常处理的基本思想是简化程序的错误代码,为程序键壮性提供一个标准检测机制。 也许我们已经使用过异常,但是你会是一种习惯吗,不要老是想着当我打开一个文件的时候才用异常判断一下,我知道对你来说你喜欢用return value或者是print error message来做,你想过这样做会导致Memory Leak,系统退出,代码重复/难读,垃圾一堆…..吗?现在的软件已经是n*365*24小时的运行了,软件的健壮已经是一个很要考虑的时候了。 自序: 对写程序来说异常真的是很重要,一个稳健的代码不是靠返回Error Message/return Value来解决的,可是往往我们从C走过来,习惯了这样的方式。 仅以本文献给今天将要来临的流星雨把,还好我能在今天白天把这写完,否则会是第4个通宵了;同时感谢Jeffrey大师,没有他的SEH理论这篇文章只能完成一半,而且所有SEH列子的构想都来自他的指导;另外要感谢Scott Read more […]

(转)c++有时比Python慢

Posted by & filed under Uncategorized.

  部门最近在搞JVM上的动态语言,比如Groovy。在享受了动态语言的种种灵活之后,性能自然而然被拿出来PK。 然后玩Python的同事就旧事重提,从网上找来一段Python代码,很多Python的人都知道了,很多C++的人也知道了,它跑得很快。 为了让文章好看一点,我来编一个故事,说,有个软件公司,正要招刚从大学毕业的C++程序员和Python程序,面试题是同一道: 有一个15万行的文档,其中很多行的内容相同的,请写一段代码,读入这文件,尽可能快地将不重复的行内容输出到新文件,注意次序不要改变”,比如,有5行内容: B1 B2 A2 B2 B1 要求新文件内容为: B1 B2 A2   小P新学习Pythont不久,他写出代码如下:

这是一段中规中矩的Pythont程序,符合Python的风格:看不出是新手还是老手写的。:) OK,在我的机器上,我准备了一个15万文字,但不重复行只有4万行的文件,上面的代码运行时间是281 Read more […]

(转)Linux守护进程的编程实现

Posted by & filed under Uncategorized.

Linux 守护进程的编程方法 守护进程(Daemon)是运行在后台的一种特殊进程。它独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。守护进程是一种很有用的进程。Linux的大多数服务器就是用守护进程实现的。比如,Internet服务器inetd,Web服务器httpd等。同时,守护进程完成许多系统任务。比如,作业规划进程crond,打印进程lpd等。 守护进程的编程本身并不复杂,复杂的是各种版本的Unix的实现机制不尽相同,造成不同Unix环境下守护进程的编程规则并不一致。这需要读者注意,照搬某些书上的规则(特别是BSD4.3和低版本的System V)到Linux会出现错误的。下面将全面介绍Linux下守护进程的编程要点并给出详细实例。 一. Read more […]

(转)Visual C++线程同步技术剖析:临界区,时间,信号量,互斥量

Posted by & filed under Uncategorized.

  使线程同步 在程序中使用多线程时,一般很少有多个线程能在其生命期内进行完全独立的操作。更多的情况是一些线程进行某些处理操作,而其他的线程必须对其处理结果进行了解。正常情况下对这种处理结果的了解应当在其处理任务完成后进行。 如果不采取适当的措施,其他线程往往会在线程处理任务结束前就去访问处理结果,这就很有可能得到有关处理结果的错误了解。例如,多个线程同时访问同一个全局变量,如果都是读取操作,则不会出现问题。如果一个线程负责改变此变量的值,而其他线程负责同时读取变量内容,则不能保证读取到的数据是经过写线程修改后的。 为了确保读线程读取到的是经过修改的变量,就必须在向变量写入数据时禁止其他线程对其的任何访问,直至赋值过程结束后再解除对其他线程的访问限制。象这种保证线程能了解其他线程任务处理结束后的处理结果而采取的保护措施即为线程同步。 线程同步是一个非常大的话题,包括方方面面的内容。从大的方面讲,线程的同步可分用户模式的线程同步和内核对象的线程同步两大类。用户模式中线程的同步方法主要有原子访问和临界区等方法。其特点是同步速度特别快,适合于对线程运行速度有严格要求的场合。 内核对象的线程同步则主要由事件、等待定时器、信号量以及信号灯等内核对象构成。由于这种同步机制使用了内核对象,使用时必须将线程从用户模式切换到内核模式,而这种转换一般要耗费近千个CPU周期,因此同步速度较慢,但在适用性上却要远优于用户模式的线程同步方式。 临界区   临界区(Critical Read more […]

(转)c++ stdio与iostream对比

Posted by & filed under Uncategorized.

  C++ iostream 的主要作用是让初学者有一个方便的命令行输入输出试验环境,在真实的项目中很少用到 iostream,因此不必把精力花在深究 iostream 的格式化与 manipulator。iostream 的设计初衷是提供一个可扩展的类型安全的 IO 机制,但是后来莫名其妙地加入了 locale 和 facet 等累赘。其整个设计复杂不堪,多重+虚拟继承的结构也很巴洛克,性能方面几无亮点。iostream 在实际项目中的用处非常有限,为此投入过多学习精力实在不值。 stdio 格式化输入输出的缺点 1. 对编程初学者不友好 看看下面这段简单的输入输出代码。

注意到其中 输入和输出用的格式字符串不一样。输入 short Read more […]