From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 08:20:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7103C106564A for ; Mon, 23 Mar 2009 08:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF6C8FC0A for ; Mon, 23 Mar 2009 08:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E35FB46B51; Mon, 23 Mar 2009 04:20:20 -0400 (EDT) Date: Mon, 23 Mar 2009 08:20:20 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yoshihiro Ota In-Reply-To: <20090322235253.432874dd.ota@j.email.ne.jp> Message-ID: References: <20090320045319.04484fc5.ota@j.email.ne.jp> <20090322235253.432874dd.ota@j.email.ne.jp> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 08:20:21 -0000 On Sun, 22 Mar 2009, Yoshihiro Ota wrote: >> On Fri, 20 Mar 2009, Yoshihiro Ota wrote: >> >>> 1. With TCP connections, only sender side can detect some communication >>> issues passively if happened. By using two connections, you lost that >>> ability by your self. I agree on this one. >> >> Could you expand a bit on this point? While the connection creation >> process (usually) asymmetric, once the connection is built it's essentially >> the same state machine on both sides of the connection, and socket >> semantics with respect to the state machine are effectively identical. >> Application on both sides should be able to detect disconnect, monitor >> connection state using TCP_INFO, etc. > > What I meant was that there were cases when a receiver could not tell > weather no data was coming or communication was interrupted. Once > connection is established, a route is available between a server and a > client. Let's say this route is broken for some reasons, i.e. someone > unplugged a cable or a firewall started dropping or rejecting between these > server and client, a sender may not notice as soon as it happens but at > least, a sender knows a massages was not delivered right. On the other > hand, receiver side does not have any idea that a message delivery failure > has happened at all or for a while unless using heartbeat messages in upper > layer. KEEP_ALIVE option seems to be implementation dependent such that you > cannot assure TCP connection availability for every minute. This is generally considered a robustness property rather than a fragility issue, but yes: if you need a liveliness property for idle connections with TCP, it's something you have to implement at the application layer, and many protocols indeed do this. I don't see that this is an argument for using two TCP connections as opposed to one, however. If you're interested in alternative protocols, however, SCTP allows a number of these protocol behaviors to be modified, and includes support for a heartbeat. Robert N M Watson Computer Laboratory University of Cambridge