襄阳市襄城区人民法院:服务器如何在SOCKET通讯中知道客户端断开连接或掉线了???[
来源:百度文库 编辑:九乡新闻网 时间:2024/05/03 12:01:39
发表于:2002-06-14 09:52:34 我用Socket做了一个服务器和客户端,服务器在客户端连接时能知道,但客户端断开或掉线服务器就不知道了,请问大虾们有好办法吗?
但如果Client端掉线就不行了,你可以通过定时检查某个连接是否有数据发送
来确定,如果长时间无数据发送就认为已掉线
http://www.csdn.net/expert/topic/563/563231.xml?temp=.297085
All of the I/O strategies discussed in the I/O strategies article have some way of indicating that the connection is closed.
First, keep in mind that TCP is a full-duplex network protocol. That means that you can close the connection half-way and still send data on the other half. An example is a web browser: it sends a short request to the web server, then closes its half of the connection. The web server then sends back the requested data on the other half of the connection, and closes its sending side, which terminates the TCP session.
Normal TCP programs only close the sending half, which the remote peer perceives as the receiving half. So, what you normally want to detect is whether the remote peer closed its sending half, meaning you won 't be receiving data from them any more.
With asynchronous sockets, Winsock sends you an FD_CLOSE message when the connection drops. Event objects are similar: the system signals the event object with an FD_CLOSE notification.
With blocking and non-blocking sockets, you probably have a loop that calls recv() on that socket. recv() returns 0 when the remote peer closes the connection. As you would expect, if you are using select(), the SOCKET descriptor in the read_fds parameter gets set when the connection drops. As normal, you 'll call recv() and see the 0 return value.
As you might have guessed from the discussion above, it is also possible to close the receiving half of the connection. If the remote peer then tries to send you data, the stack will drop that data on the floor and send a TCP RST to the remote peer.
The previous question deals with detecting when a protocol connection is dropped normally, but what if you want to detect other problems, like unplugged network cables or crashed workstations? In these cases, the failure prevents notifying the remote peer that something is wrong. My feeling is that this is usually a feature, because the broken component might get fixed before anyone notices, so why force everyone to restart?
If you have a situation where you must be able to detect all network failures, you have two options:
The first option is to give the protocol a command/response structure: one host sends a command and expects a prompt response from the other host when the command is received or acted upon. If the response does not arrive, the connection is assumed to be dead, or at least faulty.
The second option is to add an "echo " function to your protocol, where one host (usually the client) is expected to periodically send out an "are you still there? " packet to the other host, which it must promptly acknowledge. If the echo-sending host doesn 't receive its response or the receiving host fails to see an echo request for a certain period of time, the program can assume that the connection is bad or the remote host has gone down.
If you choose the "echo " alternative, avoid the temptation to use the ICMP "ping " facility for this. If you did it this way, you would have to send pings from both sides, because Microsoft stacks won 't let you see the other side 's echo requests, only responses to your own echo requests. Another problem with ping is that it 's outside your protocol, so it won 't detect a failed TCP connection if the hardware connection remains viable. A final problem with the ping technique is that ICMP is an unreliable protocol: does it make a whole lot of sense to use an unreliable protocol to add an assurance of reliability to another protocol?
Another option you should not bother with is the TCP keepalive mechanism. This is a way to tell the stack to send a packet out over the connection at specific intervals whether there 's real data to send or not. If the remote host is up, it will send back a similar reply packet. If the TCP connection is no longer valid (e.g. the remote host has rebooted since the last keepalive), the remote host will send back a reset packet, killing the local host 's connection. If the remote host is down, the local host 's TCP stack will time out waiting for the reply and kill the connection.
There are two problems with keepalives:
Only Windows 2000 allows you to change the keepalive time on a per-process basis. On older versions of Windows, changing the keepalive time changes it for all applications on the machine that use keepalives. (Changing the keepalive time is almost a necessity since the default is 2 hours.)
Each keepalive packet is 40 bytes of more-or-less useless data, and there 's one sent each direction as long as the connection remains valid. Contrast this with a command/response type of protocol, where there is effectively no useless data: all packets are meaningful. In fairness, however, TCP keepalives are less wasteful on Windows 2000 than the "are you still there " strategy above.
Note that different types of networks handle physical disconnection differently. Ethernet, for example, establishes no link-level connection, so if you unplug the network cable, a remote host can 't tell that its peer is physically unable to communicate. By contrast, a dropped PPP link causes a detectable failure at the link layer, which propagates up to the Winsock layer for your program to detect.
如果超时的话就根据你的系统KILL掉或者挂起。
这里应该设置有同步变量来控制。
你使用WSAAsyncSelect()函数,自定义消息WM_SOCKET,然后铺捉FD_ACCEPT等等,在处理消息的开始的时候先判断是否出现网络错误
如下:
case WM_SOCKET:
if(WSAGETSELECTERROR(lParam))
{
if(WSAGETSELECTERROR(lParam) == WSAECONNABORTED)
{
// 如果客户端关闭socket,就产生这个错误
}
else
{
// 其他socket错误
}
}
OK?
可以设置中断时间 如果在相隔时间内客户端没有进行任何操作 就可以设定对方超时 中断连接
推荐的方法就是如前面所说使用在线检查机制,定时传送数据报,确认对方是否还在线。路由器和路由器之间的检测就是这种形式
在Server端使用Select进行检查,同时设定TimeOut,如10分钟;
在Client端开一个线程,定一个时间,如1分钟就向Server发送一个信号,当Server端如果10分钟还收不到Client端发来的信号,就关闭该Client的服务。
- pfans
- (pfans)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bluecrest
- (高歌)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- mryinliang
- (海崖)
- 等 级:
但如果Client端掉线就不行了,你可以通过定时检查某个连接是否有数据发送
来确定,如果长时间无数据发送就认为已掉线
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- kingzai
- (时间成就一切)
- 等 级:
-
3
2
更多勋章
http://www.csdn.net/expert/topic/563/563231.xml?temp=.297085
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lakelive
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- pfans
- (pfans)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- masterz
- (ggxs)
- 等 级:
- 更多勋章
All of the I/O strategies discussed in the I/O strategies article have some way of indicating that the connection is closed.
First, keep in mind that TCP is a full-duplex network protocol. That means that you can close the connection half-way and still send data on the other half. An example is a web browser: it sends a short request to the web server, then closes its half of the connection. The web server then sends back the requested data on the other half of the connection, and closes its sending side, which terminates the TCP session.
Normal TCP programs only close the sending half, which the remote peer perceives as the receiving half. So, what you normally want to detect is whether the remote peer closed its sending half, meaning you won 't be receiving data from them any more.
With asynchronous sockets, Winsock sends you an FD_CLOSE message when the connection drops. Event objects are similar: the system signals the event object with an FD_CLOSE notification.
With blocking and non-blocking sockets, you probably have a loop that calls recv() on that socket. recv() returns 0 when the remote peer closes the connection. As you would expect, if you are using select(), the SOCKET descriptor in the read_fds parameter gets set when the connection drops. As normal, you 'll call recv() and see the 0 return value.
As you might have guessed from the discussion above, it is also possible to close the receiving half of the connection. If the remote peer then tries to send you data, the stack will drop that data on the floor and send a TCP RST to the remote peer.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- masterz
- (ggxs)
- 等 级:
- 更多勋章
The previous question deals with detecting when a protocol connection is dropped normally, but what if you want to detect other problems, like unplugged network cables or crashed workstations? In these cases, the failure prevents notifying the remote peer that something is wrong. My feeling is that this is usually a feature, because the broken component might get fixed before anyone notices, so why force everyone to restart?
If you have a situation where you must be able to detect all network failures, you have two options:
The first option is to give the protocol a command/response structure: one host sends a command and expects a prompt response from the other host when the command is received or acted upon. If the response does not arrive, the connection is assumed to be dead, or at least faulty.
The second option is to add an "echo " function to your protocol, where one host (usually the client) is expected to periodically send out an "are you still there? " packet to the other host, which it must promptly acknowledge. If the echo-sending host doesn 't receive its response or the receiving host fails to see an echo request for a certain period of time, the program can assume that the connection is bad or the remote host has gone down.
If you choose the "echo " alternative, avoid the temptation to use the ICMP "ping " facility for this. If you did it this way, you would have to send pings from both sides, because Microsoft stacks won 't let you see the other side 's echo requests, only responses to your own echo requests. Another problem with ping is that it 's outside your protocol, so it won 't detect a failed TCP connection if the hardware connection remains viable. A final problem with the ping technique is that ICMP is an unreliable protocol: does it make a whole lot of sense to use an unreliable protocol to add an assurance of reliability to another protocol?
Another option you should not bother with is the TCP keepalive mechanism. This is a way to tell the stack to send a packet out over the connection at specific intervals whether there 's real data to send or not. If the remote host is up, it will send back a similar reply packet. If the TCP connection is no longer valid (e.g. the remote host has rebooted since the last keepalive), the remote host will send back a reset packet, killing the local host 's connection. If the remote host is down, the local host 's TCP stack will time out waiting for the reply and kill the connection.
There are two problems with keepalives:
Only Windows 2000 allows you to change the keepalive time on a per-process basis. On older versions of Windows, changing the keepalive time changes it for all applications on the machine that use keepalives. (Changing the keepalive time is almost a necessity since the default is 2 hours.)
Each keepalive packet is 40 bytes of more-or-less useless data, and there 's one sent each direction as long as the connection remains valid. Contrast this with a command/response type of protocol, where there is effectively no useless data: all packets are meaningful. In fairness, however, TCP keepalives are less wasteful on Windows 2000 than the "are you still there " strategy above.
Note that different types of networks handle physical disconnection differently. Ethernet, for example, establishes no link-level connection, so if you unplug the network cable, a remote host can 't tell that its peer is physically unable to communicate. By contrast, a dropped PPP link causes a detectable failure at the link layer, which propagates up to the Winsock layer for your program to detect.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lj_csdn
- (大笨蛋)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- anjy
- (泡泡oοО○)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- danscort2000
- (带鱼)
- 等 级:
如果超时的话就根据你的系统KILL掉或者挂起。
这里应该设置有同步变量来控制。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- panyf_2k
- (backstreet)
- 等 级:
你使用WSAAsyncSelect()函数,自定义消息WM_SOCKET,然后铺捉FD_ACCEPT等等,在处理消息的开始的时候先判断是否出现网络错误
如下:
case WM_SOCKET:
if(WSAGETSELECTERROR(lParam))
{
if(WSAGETSELECTERROR(lParam) == WSAECONNABORTED)
{
// 如果客户端关闭socket,就产生这个错误
}
else
{
// 其他socket错误
}
}
OK?
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- limin
- (不留名)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- kingfire
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- mfkzj
- (鹰翔)
- 等 级:
可以设置中断时间 如果在相隔时间内客户端没有进行任何操作 就可以设定对方超时 中断连接
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- top_hipster
- (无为而无所不为)
- 等 级:
推荐的方法就是如前面所说使用在线检查机制,定时传送数据报,确认对方是否还在线。路由器和路由器之间的检测就是这种形式
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- hzyem
- (大峡)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lxiumin
- (梁爽)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dy_paradise
- (小耳朵)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- johnsonrao
- (johnson)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- vtable9999
- (肝肝肝肝)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- vtable9999
- (肝肝肝肝)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- jfzsl
- (剿匪总司令)
- 等 级:
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sans
- (长风半日)
- 等 级:
-
2
在Server端使用Select进行检查,同时设定TimeOut,如10分钟;
在Client端开一个线程,定一个时间,如1分钟就向Server发送一个信号,当Server端如果10分钟还收不到Client端发来的信号,就关闭该Client的服务。
服务器如何在SOCKET通讯中知道客户端断开连接或掉线了???[
Delphi2010中DataSnap高级技术(3)—DataSnap服务器如何得到客户端...
Delphi2010中DataSnap高级技术(3)—DataSnap服务器如何得到客户端...
您的服务器意外终止了连接。其可能原因包括服务器出错、网络出错或长时间处于非活
ado连接sql server时,如果服务器ip地址是动态的话,如何配置,能不能把ip地址保存在某个文件中
电子邮件自动断开怎么连接
CentOS--SSH服务器的构建-客户端连接配置("钥匙验证登陆")_Lee_Baidu...
如何取消连接服务器时"记住密码"
putty中解决SSH连接超时断开的两种方法 | PuTTY中文站
如何在 Windows Server 中配置权威时间服务器
如何在 Windows Server 2003 中设置 FTP 服务器
java socket 长连接 短连接
如何将网页与邮件服务器连接起来
终端服务器超出了最大允许连接数
共享服务器-----连接Oracle
专用服务器----连接Oracle
Boost socket 同步编程示例(服务端,客户端)
Qt客户端程序建立和服务器通信
C#.net同步异步SOCKET通讯和多线程总结
如何在解决方案中添加或删除 Integration Services 项目
如何在 Windows 资源管理器中显示或隐藏文件扩展名
如何在文章中左侧或右侧填加图片
如何在Word文档中“囗”打勾或叉
用串口连接GSM手机发送和接收短消息,在应用程序中如何编程实现?