免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: wishel
打印 上一主题 下一主题

推见2篇linux下高并发开发的文章 [复制链接]

论坛徽章:
0
21 [报告]
发表于 2008-11-11 11:58 |只看该作者
。。。

[ 本帖最后由 wishel 于 2008-11-11 12:32 编辑 ]

论坛徽章:
1
申猴
日期:2014-02-11 14:50:31
22 [报告]
发表于 2008-11-11 12:49 |只看该作者
上面的那段英文和我们现在讨论的"为什么在缓冲区还有数据时,close掉程序就不会走正常的关闭流程?" 不是一回事

上面的英文是 比如 :在client端接收缓冲区还有数据时,close掉client,client会发送rst给server端,但client端还是走的是正常的关闭流程,而我们讨论的是为什么client端不走正常的关闭流程

论坛徽章:
0
23 [报告]
发表于 2008-11-11 12:55 |只看该作者
原帖由 chenzhanyiczy 于 2008-11-11 12:49 发表
上面的那段英文和我们现在讨论的"为什么在缓冲区还有数据时,close掉程序就不会走正常的关闭流程?" 不是一回事

上面的英文是 比如 :在client端接收缓冲区还有数据时,close掉client,client会发送rst给serv ...


那段英文的意思是说,我们之前认为的,这是非正常关闭流程,是不准确的
这是正常的关闭流程。
4次握手并不是正常关闭流程的全部。

论坛徽章:
0
24 [报告]
发表于 2008-11-11 13:12 |只看该作者
再看rfc793:

     ESTABLISHED
      FIN-WAIT-1
      FIN-WAIT-2
      CLOSE-WAIT

        If the RST bit is set then, any outstanding RECEIVEs and SEND
        should receive "reset" responses.  All segment queues should be
        flushed.  Users should also receive an unsolicited general
        "connection reset" signal.  Enter the CLOSED state, delete the
        TCB, and return.

论坛徽章:
52
码神
日期:2017-03-28 10:27:10综合交流区版块每日发帖之星
日期:2015-10-11 06:20:00综合交流区版块每日发帖之星
日期:2015-09-28 06:20:00综合交流区版块每日发帖之星
日期:2015-09-22 06:20:00每日论坛发贴之星
日期:2015-09-12 06:20:00综合交流区版块每日发帖之星
日期:2015-09-12 06:20:00综合交流区版块每日发帖之星
日期:2015-09-08 06:20:00综合交流区版块每日发帖之星
日期:2015-09-05 06:20:00综合交流区版块每日发帖之星
日期:2015-09-04 06:20:002015亚冠之德黑兰石油
日期:2015-09-01 10:41:53每日论坛发贴之星
日期:2015-10-11 06:20:00综合交流区版块每日发帖之星
日期:2015-10-12 06:20:00
25 [报告]
发表于 2008-11-11 13:33 |只看该作者

回复 #1 wishel 的帖子

感谢。

论坛徽章:
1
申猴
日期:2014-02-11 14:50:31
26 [报告]
发表于 2008-11-11 14:03 |只看该作者
原帖由 wishel 于 2008-11-11 12:55 发表


那段英文的意思是说,我们之前认为的,这是非正常关闭流程,是不准确的
这是正常的关闭流程。
4次握手并不是正常关闭流程的全部。



就按你说的,正常的关闭流程,我们讨论的是为什么不按4次握手流程去走

论坛徽章:
0
27 [报告]
发表于 2008-11-11 14:45 |只看该作者
原帖由 chenzhanyiczy 于 2008-11-11 14:03 发表



就按你说的,正常的关闭流程,我们讨论的是为什么不按4次握手流程去走


为什么非要按4次握手流程呢?rfc1122说的很清楚了,我把这篇贴全吧

4.2.2.13  Closing a Connection: RFC-793 Section 3.5
A TCP connection may terminate in two ways: (1) the normal
            TCP close sequence using a FIN handshake, and (2) an "abort"
            in which one or more RST segments are sent and the
            connection state is immediately discarded.  If a TCP
            connection is closed by the remote site, the local
            application MUST be informed whether it closed normally or
            was aborted.

            The normal TCP close sequence delivers buffered data
            reliably in both directions.  Since the two directions of a
            TCP connection are closed independently, it is possible for
            a connection to be "half closed," i.e., closed in only one
            direction, and a host is permitted to continue sending data
            in the open direction on a half-closed connection.

            A host MAY implement a "half-duplex" TCP close sequence, so
            that an application that has called CLOSE cannot continue to
            read data from the connection.  If such a host issues a
            CLOSE call while received data is still pending in TCP, or
            if new data is received after CLOSE is called, its TCP
            SHOULD send a RST to show that data was lost.

            When a connection is closed actively, it MUST linger in
            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
            However, it MAY accept a new SYN from the remote TCP to
            reopen the connection directly from TIME-WAIT state, if it:

            (1)  assigns its initial sequence number for the new
                 connection to be larger than the largest sequence
                 number it used on the previous connection incarnation,
                 and

            (2)  returns to TIME-WAIT state if the SYN turns out to be
                 an old duplicate.


            DISCUSSION:
                 TCP's full-duplex data-preserving close is a feature
                 that is not included in the analogous ISO transport
                 protocol TP4.

                 Some systems have not implemented half-closed
                 connections, presumably because they do not fit into
                 the I/O model of their particular operating system.  On
                 these systems, once an application has called CLOSE, it
                 can no longer read input data from the connection; this
                 is referred to as a "half-duplex" TCP close sequence.

                 The graceful close algorithm of TCP requires that the
                 connection state remain defined on (at least)  one end
                 of the connection, for a timeout period of 2xMSL, i.e.,
                 4 minutes.  During this period, the (remote socket,
                 local socket) pair that defines the connection is busy
                 and cannot be reused.  To shorten the time that a given
                 port pair is tied up, some TCPs allow a new SYN to be
                 accepted in TIME-WAIT state.

看第一段

论坛徽章:
0
28 [报告]
发表于 2008-11-11 17:33 |只看该作者
原帖由 wishel 于 2008-11-10 21:36 发表
关于第一篇的TIME_WAIT问题,UNPv1 2.7说的很详细,正常情况下为什么要这样设计。而这篇文章走的一个窍门是绕过正常情况,直接使用异常关闭连接的方法。这样做不是不可以,但是使用的时候要明白自己在做什么,会 ...


没错,在没有仔细阅读过unp之前, 千万不要轻易"我发现", "我提出"... 呵呵

论坛徽章:
1
申猴
日期:2014-02-11 14:50:31
29 [报告]
发表于 2008-11-11 22:26 |只看该作者
原帖由 wishel 于 2008-11-11 14:45 发表


为什么非要按4次握手流程呢?rfc1122说的很清楚了,我把这篇贴全吧

4.2.2.13  Closing a Connection: RFC-793 Section 3.5
A TCP connection may terminate in two ways: (1) the normal
             ...



到此为止吧,我们讨论的话题都不一样

论坛徽章:
0
30 [报告]
发表于 2008-11-17 15:18 |只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP