jwybobo2007的博客

当这个选项被设置为 true（1）时，套接字将不接受IPv4映射地址，这意味着它将只接受IPv6通信。当设置为 false（0）时，套接字将同时接受IPv6通信和IPv4映射地址，使得可以在单个端口上同时监听IPv4和IPv6。需要注意的是，IPv6的万能地址绑定监听后实际是可以同时支持IPv4和IPv6的客户端连接的（双栈环境中）。为 false 在IPv4和IPv6双栈环境中非常有用，可以简化服务端的实现代码，从而减少开发工作量。另外需要注意，当有两个套接字同时监听IPv4和IPv6的相同端口，并且。

之前写过一篇文章，分析了h264使用rtp进行封包的格式介绍：RTP封装h264。但里面好像没有把拆分以及一些需要注意的情况说清楚，因此这里做补充，也作为自己的备忘（自己记性好像不太好）。关于时间戳，需要注意的是h264的采样率为90000HZ，因此时间戳的单位为1(秒)/90000，因此如果当前视频帧率为25fps，那时间戳间隔或者说增量应该为3600，如果帧率为30fps，则增量为

// 测试指定udp端口是否可以绑定,WIN32下记得要先初始化WSAStartup bool udpBindTest(uint16_t port) { SOCKET sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_IP); if (sockfd == INVALID_SOCKET) return false; struct soc

1.使用命令在bash中使用ulimit,仅对当前shell生效另外可以在bashrc等启动脚本里面加上ulimit的命令行2.使用函数在自己的程序中调用setrlimit来修改3.修改配置文件(没试过,看到别人写的)debian/redhat下修改/etc/security.limits.conf，增加类似如下两行：* soft nofile 4096* hard

#ifndef _SOCKET_TYPE_H#define _SOCKET_TYPE_H#ifdef _WIN32#include #define ERRNO (WSAGetLastError())#define NEEDBLOCK WSAEWOULDBLOCKtypedef int socklen_t;#else#include #include #include #i

文章部分借用网上搜索到的资料网络抽象层单元类型 (NALU):NALU头由一个字节组成,它的语法如下: +---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |F|NRI| Type | +---------------+F: 1

我之前编译了jrtplib 3.9.1，并且在项目中使用，结果发现在用这个库时，程序体积有增加了300多K，感觉实在是有点笨重，我无法就是用来发送rtp包而已。想想还是自己重新实现一个简单的类用用拉倒了，所以有了下面的代码。头文件：/*!@brief 简单rtp库@file easy_rtp.h*/#ifndef _EASY_RTP_H#define _EASY_RTP_H#

下载源代码这个标题用了两个顿号三个名称，其实说得是同一个东西，只是网上有不同的说法罢了，另外好像还有人叫TCP打孔（我的朋友小妞听说后问“要打孔啊，要不要我帮你去借个电钻过来啊？”“~！·￥%……·！”）。闲话少说，我们先看一下技术背景：Internet的迅速发展以及IPv4 地址数量的限制使得网络地址翻译(NAT,Network Address Trans2lation)设备得到

最近在网络上看到一些帖子以及回复，同时又搜索了一些网络上关于阻塞非阻塞的区别，发现很多人在描述两者的发送接收时操作返回以及缓冲区处理的区别时有不同程度的误解。所以我想写一篇文章来纠正错误，并作为记录方便查阅，如有转载，注明作者（jwybobo2007）以及出处即可。  首先soc

<br />不多说了，curl的http上传文件代码示例，有需要的可以参考。<br /> <br />int http_post_file(const char *url, const char *user, const char *pwd, const char *filename)<br />{<br />    assert(url != NULL);<br />    assert(user != NULL);<br />    assert(pwd != NULL);<br />

http://msdn.microsoft.com/en-us/library/ms706556%28v=VS.85%29.aspx

　　上次转载了一篇文章http://blog.youkuaiyun.com/jwybobo2007/archive/2010/12/30/6107419.aspx,上面提到了TCP窗口大小与SO_RCVBUF选项之间的关系.但其实这篇文章描述的是有问题的.　　在以Unix为核心的一些操作系统中(不一定都是),SO_RCVBUF选项确实决定了TCP窗口的大小.你设置为多少窗口就为多少.但在Windows上确并非如此,通过一些抓包工具分析后,你会发现这两者并不是一一对应关系,MSDN的说明上确实也告知这一事实.　　如使

TCP异常断开是指在突然断电,直接拔网线等等情况下,如果通信双方没有进行数据发送通信等处理的时候,无法获知连接已经断开的情况. 在通常的情况下,为了使得socket通信不受操作系统的限制,需要自己在应用层实现心跳包机制,来检查异常断开的情况,一般的方式就是服务器在一段时间没有收到客户端数据包时,定时发包,然后客户端回应,如果已经出现异常断开则服务器接收会返回错误,而客户端在指定时间内没有收到数据包,则主动向服务器发包,得到错误就说明断开.诸如此类的方式就是自己实现的心跳包机制. 但操作系统本身也自带

一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数二、对于server端的socket一定要在listen之间设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大小。对于client端的socket一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在connet之后再设置缓冲区，已经没有什么意义。三、由于缓冲区大小在TCP头部只有16位来表示，所以它的最大值是65536，但是对于一些情况来说需要使

TIME_WAIT状态 TCP要保证在所有可能的情况下使得所有的数据都能够正确被投递。当关闭一个 socket 连接时，主动关闭一端的 socket 将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态。见图解。当一个socket关闭的时候，是通过两端互发信息的四次握手过程完成的，当一端调用close()时，就说明本端没有数据再要发送了。这好似看来在握手完成以后，socket就都应该处于关闭CLOSED状态了。但这有两个问题， 第一：我们没有任何机制保证最后的一个ACK能够正常送达 第二：网络