2015年3月 总版技术专家分月排行榜第二2014年12月 总版技术专家分月排行榜第二2014年9月 总版技术专家分月排行榜第二
2015年3月 .NET技术大版内专家分月排行榜第一2015年2月 .NET技术大版内专家分月排行榜第一2015年1月 .NET技术大版内专家分月排行榜第一2014年12月 .NET技术大版内专家分月排行榜第一2014年11月 .NET技术大版内专家分月排行榜第一
2015年3月 总版技术专家分月排行榜第二2014年12月 总版技术专家分月排行榜第二2014年9月 总版技术专家分月排行榜第二
2015年3月 .NET技术大版内专家分月排行榜第一2015年2月 .NET技术大版内专家分月排行榜第一2015年1月 .NET技术大版内专家分月排行榜第一2014年12月 .NET技术大版内专家分月排行榜第一2014年11月 .NET技术大版内专家分月排行榜第一
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。09:42 by youxin, ... 阅读,
一篇文章：
最近在做一个服务器端程序，C/S结构。功能方面比较简单就是client端与server端建立连接，然后发送消息给server。我在server端会使用专门的线程处理一条socket连接。这就涉及到一个问题，如果socket连接断开（异常，正常）后，我如何才能感知到？server端这边是绝对被动的，sever端不能主动断开连接。也没有连接链路维持包之类的。client端发送数据的时间也是不定的。在socket连接断开后， server要能够感知到并释放资源。这个问题在思考测试，询问同事之后，找到了一个方法，可以做到这一点。当使用 select()函数测试一个socket是否可读时，如果select()函数返回值为1，且使用recv()函数读取的数据长度为0 时，就说明该socket已经断开。为了更好的判定socket是否断开，我判断当recv()返回值小于等于0时，socket连接断开。但是还需要判断 errno是否等于 EINTR 。如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的，socket连接还是正常的，不应close掉socket连接。PS：对于堵塞socket的recv函数会在以下三种情况下返回：（1）recv到数据时，会返回。（2）在整个程序接收到信号时，返回-1。errno = EINTR。//在程序的起始阶段，屏蔽掉信号的除外。部分信号还是屏蔽不掉的。（3）socket出现问题时，返回-1.具体错误码看 man recv()（4）一定要看 man 说明，很详细，很有帮助。这种方法经过长时间测试后，是有效的。所以写出来让大家参考一下，请大家发表意见。
tcp会自动断开连接吗？
已经建立了TCP连接，并可能互通信息。但是如果长时间不进行信息的传递。这个TCP连接会自动断开吗？如果能自动断开的话，这个时间大约是多少呢？
回答：TCP的保活定时器能够保证TCP连接一直保持，但是TCP的保活定时器不是每个TCP/IP协议栈就实现了，因为RFC并不要求TCP保活定时器一定要实现。摘自《TCP/IP详解》卷1第23章：保活并不是T&C&P规范中的一部分。Host&Requirements&RFC提供了3个不使用保活定时器的理由：&(1)&在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉；（2）它们耗费不必要的带宽；（3）在按分组计费的情况下会在互联网上花掉更多的钱。然而，许多实现提供了保活定时器。更具体的资料，请参阅RFC。
tcp/ip详解更全面的描述：
在一个空闲的（idle）TCP连接上，没有任何的数据流，许多TCP/IP的初学者都对此感到惊奇。也就是说，如果TCP连接两端没有任何一个进程在向对方发送数据，那么在这两个TCP模块之间没有任何的数据交换。你可能在其它的网络协议中发现有轮询（polling），但在TCP中它不存在。言外之意就是我们只要启动一个客户端进程，同服务器建立了TCP连接，不管你离开几小时，几天，几星期或是几个月，连接依旧存在。中间的路由器可能崩溃或者重启，电话线可能go down或者back up，只要连接两端的主机没有重启，连接依旧保持建立。
这就可以认为不管是客户端的还是服务器端的应用程序都没有应用程序级（application-level）的定时器来探测连接的不活动状态（inactivity），从而引起任何一个应用程序的终止。回忆在10.7结束，BGP每隔30秒就向对方发送一个应用程序探测。这是一个应用程序定时器（application timer），与TCP存活定时器不同。
然而有的时候，服务器需要知道客户端主机是否已崩溃并且关闭，或者崩溃但重启。许多实现提供了存活定时器来完成这个任务。
存活（keepalive）并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。
存活定时器是一个包含争议的特征。许多人认为，即使需要这个特征，这种对对方的轮询也应该由应用程序来完成，而不是由TCP中实现。一些人对这个话题表现了极大的热情，甚至达到宗教般的狂热。
如果两个终端系统之间的某个中间网络上有连接的暂时中断，那么存活选项（option）就能够引起两个进程间一个良好连接的终止。例如，如果正好在某个中间路由器崩溃、重启的时候发送存活探测，TCP就将会认为客户端主机已经崩溃，但事实并非如此。
一些服务器应用程序可能代表客户端占用资源，它们需要知道客户端主机是否崩溃。存活定时器可以为这些应用程序提供探测服务。Telnet服务器和Rlogin服务器的许多版本都默认提供存活选项。
个人计算机用户使用TCP/IP协议通过Telnet登录一台主机，这是能够说明需要使用存活定时器的一个常用例子。如果某个用户在使用结束时只是关掉了电源，而没有注销（log off），那么他就留下了一个半打开（half-open）的连接。在图18.16，我们看到如何在一个半打开连接上通过发送数据，得到一个复位（reset）返回，但那是在客户端，是由客户端发送的数据。如果客户端消失，留给了服务器端半打开的连接，并且服务器又在等待客户端的数据，那么等待将永远持续下去。存活特征的目的就是在服务器端检测这种半打开连接。
我的方法不一样，我用getsockopt来判断，还是蛮准确的&
int&SocketConnected(int&sock)&
if(sock&=0)&
return&0;&
struct&tcp_&
int&len=sizeof(info);&
getsockopt(sock,&IPPROTO_TCP,&TCP_INFO,&&info,&(socklen_t&*)&len);&
if((info.tcpi_state==TCP_ESTABLISHED))&
//myprintf("socket connected\n");&
return&1;&
//myprintf("socket disconnected\n");&
return&0;&
tcp_info和TCP_ESTABLISHED在
#include &linux/types.h&#include &asm/byteorder.h&#include &linux/config.h&#include &&#include &&#include &&
int SocketConnected(int sock)&{&if(sock&=0)&return 0;&struct tcp_&int len=sizeof(info);&getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&len);&if((info.tcpi_state==TCP_ESTABLISHED))&{&//myprintf("socket connected\n");&return 1;&}&else&{&//myprintf("socket disconnected\n");&return 0;&}&}
目前主要有三种方法来实现用户掉线检测：SO_KEEPALIVE ,SIO_KEEPALIVE_VALS 和Heart-Beat线程。
下面我就上面的三种方法来做一下介绍。
(1)SO_KEEPALIVE 机制
&& & & &这是socket库提供的功能，设置接口是setsockopt API：
&& BOOL bSet=TRUE;
&& setsockopt(hSocket,SOL_SOCKET,SO_KEEPALIVE,(const char*)&bSet,sizeof(BOOL));
&& & & 根据MSDN的文档，如果为socket设置了KEEPALIVE选项，TCP/IP栈在检测到对方掉线后，
&& 任何在该socket上进行的调用(发送/接受调用)就会立刻返回，错误号是WSAENETRESET ；
&& 同时，此后的任何在该socket句柄的调用会立刻失败，并返回WSAENOTCONN错误。
&& 该机制的缺点也很明显：
&& & & & 默认设置是空闲2小时才发送一个&保持存活探测分节&，不能保证实时检测！
&& 当然也可以修改时间间隔参数，但是会影响到所有打开此选项的套接口！
&& & & & 关联了完成端口的socket可能会忽略掉该套接字选项。
(2)SIO_KEEPALIVE_VALS 机制
&& & & & 设置接口是WSAIoctl API:
&& & DWORD dwError = 0L ;
&& & tcp_keepalive sKA_Settings = {0}, sReturned = {0} ;
&& & sKA_Settings.onoff = 1 ;
&& & sKA_Settings.keepalivetime = 5500 ; // Keep Alive in 5.5 sec.
&& & sKA_Settings.keepaliveinterval = 3000 ; // Resend if No-Reply
&& & if (WSAIoctl(skNewConnection, SIO_KEEPALIVE_VALS, &sKA_Settings,
&& & & & &sizeof(sKA_Settings), &sReturned, sizeof(sReturned), &dwBytes,
&& & & & &NULL, NULL) != 0)
&& & & & & dwError = WSAGetLastError() ;
&& & 实现时需要添加tcp_keepalive and SIO_KEEPALIVE_VALS的定义文件MSTCPiP.h
&& & 该选项不同于SO_KEEPALIVE 机制的就是它是针对单个连接的，对系统其他的套接
&& & 口并不影响。
&& & & &针对完成端口的socket,设置了SIO_KEEPALIVE_VALS后，激活包由TCP STACK来负责。
&& & 当网络连接断开后，TCP STACK并不主动告诉上层的应用程序，但是当下一次RECV或者SEND操作
&& & 进行后，马上就会返回错误告诉上层这个连接已经断开了.如果检测到断开的时候，在这个连接
&& & 上有正在PENDING的IO操作，则马上会失败返回.
&& & 该机制的缺点：
&& & & & & & 不通用啦。MS的API只能用于Windows拉。不过，优雅一些^_^.
(3)Heart-Beat线程
&& & & &没说的。自己写一个后台线程，实现Heart-Beat包，客户端受到该包后，立刻返回相应的反馈 包。
&& &该方法的好处是通用，但缺点就是会改变现有的通讯协议！
/* Net check Make sure you have not used OUT OF BAND DATA AND YOU CAN use OOB */
int netcheck(int fd)
int buf_size = 1024;
char buf[buf_size];
//clear OOB DATA
recv(fd, buf, buf_size);
if(send(fd, (void *)"\0", 1, MSG_OOB) & 0 )
fprintf(stderr, "Connection[%d] send OOB failed, %s", fd, strerror(errno));
return -1;
/* Setting SO_TCP KEEPALIVE */
//int keep_alive = 1;//设定KeepAlive
//int keep_idle = 1;//开始首次KeepAlive探测前的TCP空闭时间
//int keep_interval = 1;//两次KeepAlive探测间的时间间隔
//int keep_count = 3;//判定断开前的KeepAlive探测次数
void set_keepalive(int fd, int keep_alive, int keep_idle, int keep_interval, int keep_count)
int opt = 1;
if(keep_alive)
if(setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE,
(void*)&keep_alive, sizeof(keep_alive)) == -1)
fprintf(stderr,
"setsockopt SOL_SOCKET::SO_KEEPALIVE failed, %s\n",strerror(errno));
if(setsockopt(fd, SOL_TCP, TCP_KEEPIDLE,
(void *)&keep_idle,sizeof(keep_idle)) == -1)
fprintf(stderr,
"setsockopt SOL_TCP::TCP_KEEPIDLE failed, %s\n", strerror(errno));
if(setsockopt(fd,SOL_TCP,TCP_KEEPINTVL,
(void *)&keep_interval, sizeof(keep_interval)) == -1)
fprintf(stderr,
"setsockopt SOL_tcp::TCP_KEEPINTVL failed, %s\n", strerror(errno));
if(setsockopt(fd,SOL_TCP,TCP_KEEPCNT,
(void *)&keep_count,sizeof(keep_count)) == -1)
fprintf(stderr,
"setsockopt SOL_TCP::TCP_KEEPCNT failed, %s\n", strerror(errno));
keep alive VS heart beart:
这周在上班的路上看了本书《Effective TCP/IP Programming》，以下是一些读书笔记。顺带推荐一下这本书，写的很棒，适用于像我这样经常要写一些有一定质量的网络编程，但又没时间啃那些讲解TCPIP协议大部头书的人。
很多人都知道TCP并不会去主动检测连接的丢失，这意味着，如果双方不产生交互，那么如果网络断了或者有一方机器崩溃，另外一方将永远不知道连接已经不可用了。检测连接是否丢失的方法大致有两种：keepalive和heart-beat。
Keepalive是很多的TCP实现提供的一种机制，它允许连接在空闲的时候双方会发送一些特殊的数据段，并通过响应与否来判断连接是否还存活着（所谓keep~~alive）。我曾经写过一篇&，但后来我也发现，其实keepalive在实际的应用中并不常见。为何如此？这得归结于keepalive设计的初衷。Keepalive适用于清除死亡时间比较长的连接。&比如这样的场景：一个用户创建tcp连接访问了一个web服务器，当用户完成他执行的操作后，很粗暴的直接拨了网线。这种情况下，这个tcp连接已经断开了，但是web服务器并不知道，它会依然守护着这个连接。如果web server设置了keepalive，那么它就能够在用户断开网线的大概几个小时以后，确认这个连接已经中断，然后丢弃此连接，回收资源。采用keepalive，它会先要求此连接一定时间没有活动（一般是几个小时），然后发出数据段，经过多次尝试后（每次尝试之间也有时间间隔），如果仍没有响应，则判断连接中断。可想而知，整个周期需要很长的时间。所以，如前面的场景那样，需要一种方法能够清除和回收那些在系统不知情的情况下死去了很久的连接，keepalive是非常好的选择。&但是，在大部分情况下，特别是分布式环境中，我们需要的是一个能够快速或者实时监控连接状态的机制，这里，heart-beat才是更加合适的方案。&Heart-beat（心跳），按我的理解，它的原理和keepalive非常类似，都是发送一个信号给对方，如果多次发送都没有响应的话，则判断连接中断。它们的不同点在于，keepalive是tcp实现中内建的机制，是在创建tcp连接时通过设置参数启动keepalive机制；而heart-beat则需要在tcp之上的应用层实现。一个简单的heart-beat实现一般测试连接是否中断采用的时间间隔都比较短，可以很快的决定连接是否中断。并且，由于是在应用层实现，因为可以自行决定当判断连接中断后应该采取的行为，而keepalive在判断连接失败后只会将连接丢弃。关于heart-beat，一个非常有趣的问题是，应该在传输真正数据的连接中发送&心跳&信号，还是可以专门创建一个发送&心跳&信号的连接。比如说，A，B两台机器之间通过连接m来传输数据，现在为了能够检测A，B之间的连接状态，我们是应该在连接m中传输&心跳&信号，还是创建新的连接n来专门传输&心跳&呢？我个人认为两者皆可。如果担心的是端到端的连接状态，那么就直接在该条连接中实现&心跳&。但很多时候，关注的是网络状况和两台主机间的连接状态，这种情况下， 创建专门的&心跳&连接也未尝不可。2011年 总版技术专家分年内排行榜第三2010年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第五
本帖子已过去太久远了，不再提供回复功能。帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:75&分页:一曲肝肠断发信人: wuqing (叶子), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 14:23:22 2005), 转信 &&&& 【 在 hellguard (小四★你说你最爱丁香花⊙) 的大作中提到: 】
:& 客户端突然间断开（比如死机或者拔掉网线），服务器端如何判断与之对应&& :& 的tcp连接已经断开（即判断server中一个socket文件描述符是无效的），&& :& 可以不实时的检测到，只要我去测试时能发现就行了？&& :& 我开始时想用非阻塞方式read这个连接，但是read的话，只要没有数据可读，&& :& 就返回－1，所以没法判断。&& :& 测试时，不能影响客户端，即不能往客户端写没用的数据。&&&& :他那个办法真能解决你的原始需求？我没看出来可以啊。&& 基本可行 && :你这个需求现实版一下，A用nc -l -p 7474侦听一个端口，然后B机用nc -n A 7474&& :去连，突然，我拨掉了B到A之间的路由器上的一根网线，这个时候你想让A能发现B挂&& :了、不参与通信了。&&&& :首先，这个时候你不乱动A、B的话，这条TCP连接不算挂了，等你插上网线，一切就&& :都恢复了。那个socket仍算有效的。你的原始需求包含这种情况吗？&& 依然可以发送诊断包，但是无法接收。指定时间内连续没有收到客户端的诊断包，服务器端可以采取措施，如重新启动服务。如果插上网线一切恢复而没有诊断包超时的话，不正好又可以收到诊断包了吗？诊断包超时计数重新开始呀 && :其次，B是你完全不可控的，你不能假设B会发送什么，何时发送，可以接收什么，是&& :这个意思吗？&& 不是完全不可控，只是没有源代码，有DLL就可以封装，看楼主的意思是尽量不修改客户端 && :那我觉得真正可行的还就是前面有些人说的，超时机制。基于一个超时就认为挂了的&& :假设。select/poll什么的都成，到了某个超时无来自B的数据，就认为B挂了。&& 主要是超时时间不好设置？您说多长合适？而且也如您所说：“就认为B挂了”，只是认为而已。所以理论上如您所说，超时机制最适合，但是可能不会是TCP的超时机制转而采用应用超时机制。 && :可能你真正想问的是，B有可能正常情况下长时间不向A发送数据，你想将这种情况与&& :挂了区分开，是不是这才是你的原始需求？如果是这样，那只能具体到B、A之间的正&& :常通信都是如何约定的，然后在这种约定(实际就是上层协议实现了)中寻找办法，而&& :不能指望在TCP层找办法了。
对，除Windows 完成端口以外很难在TCP层找到这样的实现办法（还不影响性能），所以才需要采用类似与TCP三次握手协议的东西放到应用层，不是最好的选择，但是是一个可用的选择。 && 当然了，如果楼主把应用需求 描述更清楚，可能会出更多的好主意。 &&&& --
不管我们相隔多远，我们看到的都是同一个月亮! &&&& ※ 修改:·wuqing 於 Nov 18 14:25:29 修改本文·[FROM: 218.249.16.*]
※ 来源:·水木社区 ·[FROM: 218.249.16.*]
一曲肝肠断发信人: wuqing (叶子), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 14:29:49 2005), 转信 &&&& 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: 不是说不能改client吗
这个估计不是做作业，所以我是从实用的角度去讨论，而不是从纯粹的理论来解决
如果只从理论，那么就把WinSock2的一些优秀特性移植过来不就可以了吗？只是移植也没有那么简单啊，就像Unix的稳定性，虽然BSD等那么多开源的操作系统存在，但微软的windows就是没有Unix稳定呢？ && 其实我提供的也只是一个参考方法而已，不是最佳解决方案。不用那么在意。 &&&& --
不管我们相隔多远，我们看到的都是同一个月亮! &&&& ※ 来源:·水木社区 ·[FROM: 218.249.16.*]
&发信人: LogIn.bbs@bbs. (游走), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 瀚海星云 (Fri Nov 18 15:02:30 2005)
转信站: NEWSMTH!news.newsmth.org!news2.happynet.org!bbsnews.!USTC && 根据lz对问题的描述
应该是不能改client，不能往client发多余的数据 && 【 在 -SPAM.no (叶子) 的大作中提到: 】
: 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: : 不是说不能改client吗
: 这个估计不是做作业，所以我是从实用的角度去讨论，而不是从纯粹的理论来解决
: 如果只从理论，那么就把WinSock2的一些优秀特性移植过来不就可以了吗？只是移植也没有那么简单啊，就像Unix的稳定性，虽然BSD等那么多开源的操作系统存在，但微软的windows就是没有Unix稳定呢？
: 其实我提供的也只是一个参考方法而已，不是最佳解决方案。不用那么在意。
&一曲肝肠断发信人: wuqing (叶子), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 15:16:20 2005), 转信 &&&& 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: 根据lz对问题的描述
: 应该是不能改client，不能往client发多余的数据
可以让客户端连接服务器以后主动发送，服务器可以根据是否定时收到客户端数据判断连接状态啊，在应用中要不要调用SendDiagnosisPack和要不要发送ResponseDiagnosisPack完全根据具体情况来啊 && 再一个，修改不修改client其实是可以协调的，即使合同上这样写，很多东西都是可以谈的，对不对？要实现这个看起来非常简单的功能（肯定是实时性方面的一些要求嘛）如果一定要改客户端的话，你认为客户会坚持说“绝对”不能改吗？ && 但是我们确实可以就此问题一起讨论，找出一些好的解决办法来 &&&&&& --
不管我们相隔多远，我们看到的都是同一个月亮! &&&& ※ 来源:·水木社区 ·[FROM: 218.249.16.*]
小鱼儿.煋.名主有花发信人: sando (小鱼儿·笑), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 15:20:51 2005), 转信 && 通讯的问题，只通过改一方是很难让整体有本质提高的
【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: 根据lz对问题的描述
: 应该是不能改client，不能往client发多余的数据
&&&& -- && &&&&&&&&&&&&也不知怎的，小鱼儿突然觉得心里甜了起来，全身飘飘然，就好像&&
&&&&&&&&一跤跌进成堆的棉花糖里。&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&但他立刻告诉自己："江鱼，小心些，这糖里是有毒的。"他立刻想&&
&&&&&&&&把铁心兰往外推，不知怎的，却推不下手。&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 166.111.203.*]
&发信人: LogIn.bbs@bbs. (游走), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 瀚海星云 (Fri Nov 18 15:29:28 2005)
转信站: NEWSMTH!news.newsmth.org!news.!news.happynet.org!bbsnews.sd && 比方说，写一个代理服务器
... && 【 在 -SPAM.no (小鱼儿·笑) 的大作中提到: 】
: 通讯的问题，只通过改一方是很难让整体有本质提高的
: 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: : 根据lz对问题的描述
: : 应该是不能改client，不能往client发多余的数据
&&发信人: LogIn.bbs@bbs. (游走), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 瀚海星云 (Fri Nov 18 15:29:12 2005)
转信站: NEWSMTH!news.newsmth.org!bbsnews.!USTC && o && 【 在 -SPAM.no (叶子) 的大作中提到: 】
: 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: : 根据lz对问题的描述
: : 应该是不能改client，不能往client发多余的数据
: 可以让客户端连接服务器以后主动发送，服务器可以根据是否定时收到客户端数据判断连接状态啊，在应用中要不要调用SendDiagnosisPack和要不要发送ResponseDiagnosisPack完全根据具体情况来啊
: 再一个，修改不修改client其实是可以协调的，即使合同上这样写，很多东西都是可以谈的，对不对？要实现这个看起来非常简单的功能（肯定是实时性方面的一些要求嘛）如果一定要改客户端的话，你认为客户会坚持说“绝对”不能改吗？
: 但是我们确实可以就此问题一起讨论，找出一些好的解决办法来
&&发信人: duduzhu.bbs@bbs. (du ran之间，迸出了爱情的火花), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 瀚海星云 (Fri Nov 18 15:30:10 2005)
转信站: NEWSMTH!news.newsmth.org!news.happynet.org!bbsnews.!USTC && 娃哈哈哈哈哈哈
【 在 LogIn (游走) 的大作中提到: 】
: 比方说，写一个代理服务器
: 【 在 -SPAM.no (小鱼儿·笑) 的大作中提到: 】
: : 通讯的问题，只通过改一方是很难让整体有本质提高的
&一曲肝肠断发信人: wuqing (叶子), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 15:36:12 2005), 转信 &&&& 【 在 LogIn.bbs@bbs. (游走) 的大作中提到: 】
: 比方说，写一个代理服务器
&& 我觉得您不能这样去比方说，那是把简单的问题复杂化，不是解决问题的思路。
就事论事，你觉得写一个代理服务器麻烦一些还是...？
好好想想还有什么好的办法在Unix下实现连接状态检测吧，大家一起想想办法 && --
不管我们相隔多远，我们看到的都是同一个月亮! &&&& ※ 来源:·水木社区 ·[FROM: 218.249.16.*]
爱护牙齿发信人: yanghsu (最爱飞行), 信区: NetPRG
标&&题: Re: 请教，如何判断一个tcp连接已经断开
发信站: 水木社区 (Fri Nov 18 15:43:51 2005), 转信 && 看来只能在应用层协议加上链路测试，就跟ftp的idle类似 && 【 在 wuqing (叶子) 的大作中提到: 】
: 我觉得您不能这样去比方说，那是把简单的问题复杂化，不是解决问题的思路。
: 就事论事，你觉得写一个代理服务器麻烦一些还是...？
: 好好想想还有什么好的办法在Unix下实现连接状态检测吧，大家一起想想办法
: ...................
南帝补钙 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 211.99.152.*]
文章数:75&分页:
抽奖到手软！将狂欢进行到底！