From owner-freebsd-net@freebsd.org Mon Mar 20 20:44:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96011D14E3C for ; Mon, 20 Mar 2017 20:44:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 804B0156B for ; Mon, 20 Mar 2017 20:44:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KKiRaI047307 for ; Mon, 20 Mar 2017 20:44:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 20:44:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #68 from Michael Tuexen --- (In reply to slw from comment #67) > Loss of sended application data caused by close() before incoming user > data arrived? Realy? TCP don't have such claim. Hmm. My understanding is that TCP provides a reliable bi-directional byte-stream. This means that no user data is lost in any of the two directions. > No problem. This is not application data. For me it doesn't matter in which direction user data is dropped. If that happens, TCP fails. > I am not afraid about user data, I am afraid about server data. > Server data lost and this is problem. > No problem about lose user data. I don't agree. TCP does not provide a service which is reliable in one direction and unreliable in the other. If user data is dropped, the connection failed. RFC 793 only talks about the CLOSE primitive, which shuts down only the wri= ting direction, not the reading one. This is not related to the close() call, the program is using. The problem comes up because the reading direction is shut down. = This is not described in the RFC. Therefore you have to go back to the high level description of the service TCP provides. --=20 You are receiving this mail because: You are the assignee for the bug.=