SO_LINGER和优雅关闭连接

http://blog.csdn.net/ccnyou/article/details/8913334

原文:http://unliminet.blog.51cto.com/380895/346686

当调用closesocket关闭套接字时,SO_LINGER将决定系统如何处理残存在套接字发送队列中的数据。处理方式无非两种:丢弃或者将数据继续发送至对端,优雅关闭连接。事实上,SO_LINGER并不被推荐使用,大多数情况下我们推荐使用默认的关闭方式(即下方表格中的第一种情况)。

下方代码段显示linger结构语法,表格为不同参数情况下的套接字行为。

  1. typedef struct linger {
  2. u_short l_onoff;    //开关,零或者非零
  3. u_short l_linger;   //优雅关闭最长时限
  4. } linger;
l_onoff l_linger closesocket行为 发送队列 底层行为
忽略 立即返回。 保持直至发送完成。 系统接管套接字并保证将数据发送至对端。
非零 立即返回。 立即放弃。 直接发送RST包,自身立即复位,不用经过2MSL状态。对端收到复位错误号。
非零 非零 阻塞直到l_linger时间超时或数据发送完成。(套接字必须设置为阻塞zhuan) 在超时时间段内保持尝试发送,若超时则立即放弃。 超时则同第二种情况,若发送完成则皆大欢喜。

可参考的资料:

http://msdn.microsoft.com/en-us/library/ms737582(v=VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms739165(v=VS.85).aspx

http://blog.csdn.net/factor2000/archive/2009/02/23/3929816.aspx

时间: 2024-10-11 06:27:13

SO_LINGER和优雅关闭连接的相关文章

SO_LINGER实现优雅关闭连接

当调用closesocket关闭套接字时,SO_LINGER将决定系统如何处理残存在套接字发送队列中的数据.处理方式无非两种:丢弃或者将数据继续发送至对端,优雅关闭连接.事实上,SO_LINGER并不被推荐使用,大多数情况下我们推荐使用默认的关闭方式(即下方表格中的第一种情况). 下方代码段显示linger结构语法,表格为不同参数情况下的套接字行为. typedef struct linger { u_short l_onoff;    //开关,零或者非零 u_short l_linger; 

boost::asio 连接管理11 如何关闭连接

在实际产品运行中,对连接管理有了更新的认识,这里分享一下. shared_ptr管理连接对象的生命周期 shared_ptr的引用计数器决定了连接对象的生命周期.这里我说的连接对象就是在我的前文:http://blog.csdn.net/csfreebird/article/details/8522620 中的Client对象: [cpp] view plaincopyprint? #include "core/connection.h" #include <vector>

优雅关闭web服务的方式

优雅关闭web服务 DBHelper, err = gorm.Open("mysql", "root:[email protected](115.159.59.129:3306)/test?charset=utf8&parseTime=True&loc=Local") if err != nil { log.Fatal("数据库初始化错误", err) //log.Fatal输出日志并且退出主程序 return } 优雅的关闭se

【HTTP】如何正常关闭连接

参考:<HTTP权威指南> 所有HTTP客户端.服务器或者代理都可以任意时刻关闭一条TCP传输连接.但是服务器永远无法确定它关闭"空闲"连接的那一刻,在线路那一头的客户端有没有数据要发送. 每条HTTP响应都应该有精确的Content-Length首部,用来描述响应主体的尺寸.如果老的HTTP服务器省略了Content-Length或者包含错误的长度指示,这样就要依赖服务器发出连接关闭来说明数据的真实末尾. 如果一个事务,不管是执行一次还是很多次,得到的结果都相同,这个事务

TCP三次握手(建立连接)/四次挥手(关闭连接)

相对于SOCKET开发者,TCP创建过程和链接折除过程是由TCP/IP协议栈自动创建的.因此开发者并不需要控制这个过程.但是对于理解TCP底层运作机制,相当有帮助. 而且对于有网络协议工程师之类笔试,几乎是必考的内容.因此在这里详细解释一下这两个过程. TCP数据包格式 顺序号( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流,它表示在这个报文段中的第一个数据字节的顺序号.如果将字节流看作在两个应用程序间的单向流动,则TCP用顺序号对每个字节进行计数.序号是32bit的无

c#对数据库访问完应关闭连接

1.对数据库的连接SqlConnection con = new SqlConnection(constr);使用完成后,应该至少应该close或dispose关闭.否则会导致数据库例如(SQl2005)中处于sleeping的进程增加并且不能自己销毁,最终会导致出现"“连接超时,已经到达最大连接数等信息”.       其解决方法:见微软的官方说明“如果 SqlConnection 超出范围,则不会将其关闭.因此,除非将代码放在 using 语句内,否则必须调用 Close 或 Dispose

java连接oracle数据库,关闭连接出现异常:java.sql.SQLRecoverableException: IO Error: Connection reset

java.sql.SQLRecoverableException: IO Error: Connection reset at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:612) at oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:5094) at com.sms.send.StartTaskNew.run(SmsSend.java

关于TCP主动关闭连接中的wait_timeout

首先我们先来回顾一下tcp关闭连接的过程: 假设A和B连接状态为EST,A需要主动关闭: A发送FIN给B,并将状态更改为FIN_WAIT1, B接收到FIN将状态更改为CLOSE_WAIT,并回复ACK和FIN A收到ACK后将状态更改为FIN_WAIT2,收到FIN后,更改状态为WAIT_TIMEOUT并给B返回ACK B收到ACK后,将关闭自己的链接CLOSE. 问题就在此时,A将处于WAIT_TIMEOUT状态长达2MSL时常(RFC793定义了MSL为2分钟,Linux设置成了30s)

WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭

原文:WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭 在我们开发WCF项目的时候,常常会碰到一些莫名其妙的错误,有时候如果根据它的错误提示信息,一般很难定位到具体的问题所在,而由于WCF服务的特殊性,调试起来也不是那么方便,因此往往会花费不少时间来进行跟踪处理.本文介绍我在我在我的框架里面使用WCF服务的时候,出现的一个常见错误的处理方法,它的提示信息是:基础连接已经关闭: 连接被意外关闭.这种情况我碰到的有两种,一种是返回DataTable的时候出现的,一种是返回实体类