我做一个与服务器通信的程序，目前可以正常的收取数据，但是在接受视频数据时到大概2分钟的时候会死掉，请各位指教，我会一直关注的，要相关代码的请讲

把自己recv的buf设置大一点。

此外，还可以把底层的接受缓冲区设置大。

http://blog.csdn.net/hairetz/archive/2009/04/16/4083389.aspx

在send()的时候，返回的是实际发送出去的字节(同步)或发送到socket缓冲区的字节
(异步);系统默认的状态发送和接收一次为8688字节(约为8.5K)；在实际的过程中发送数据
和接收数据量比较大，可以设置socket缓冲区，而避免了send(),recv()不断的循环收发：
// 接收缓冲区
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
//发送缓冲区
int nSendBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int));

我能想到的情况有以下几点：

1、客户端和服务器端，哪个先死？这个非常重要！哪一段主动打死的连接

2、网络是否稳定？比如，会不会是server端重发消息太多，导致缓冲区满了所致。或者链路层外发消息队列满了，

导致无法接受新进的上层消息等。

3、进程运行状态是否异常

4、能否抓到交互的包？

冲你的描述，猜测一个原因：你在client端接收数据，但是在接受大概两分钟的时候，通信就会终止，对吧？

你检查一下client端接收进程的缓冲区是否足够，如果缓冲区不够，程序要是越界了，可能会被OS杀掉。

注意一下你的多线程或多进程处理，是否有互斥同步的不够的地方...
你可以先测试一下单一进程或单一线程的方式，
也测试一下只接收一个服务器源数据的方式...

貌似 104 是这个吧：

#define ECONNRESET      104     /* Connection reset by peer */

程序死掉了，去抓包干什么？ 抓到包又能干什么呢？
程序死掉一般都是内存非法操作，所以-g参数重新编译你的程序，然后修改linux环境，让程序死掉的时候自动生成core文件，最后用gdb分析core文件。看到低是执行到哪一条语句出错了。
怎么修改linux环境生成core文件，自已去google一下。

最好有 wireshark 抓包的，贴上来看看...

提个傻办法，再起一个进程来监控。检测不到就重启一个。2分钟会死掉，怎么看好像是资源被占用没被释放？程序大，功能多的话，建议屏蔽掉一定功能再测试。如果还死，就说明问题在现存的功能内。然后继续分离排除吧。。

你可以这样测试一下，你把缓冲区增大或者缩小一倍。如果是因为缓冲区引起的问题，那接收数据的时间就会变

为原来的一半或者一倍，然后程序才能crash掉。

如果真是这个问题，那没办法了，你只能增大缓冲区，然后分步接收数据，这样能保证用最少的缓冲实现连续播放

看下errono是什么？

那返回 -1 后，errno 是什么...

104就是连接已经复位了，也就是这个连接已经由另一端断开了。