From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 03:53:01 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 EC875106566B for ; Mon, 23 Mar 2009 03:53:01 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id B48A88FC1A for ; Mon, 23 Mar 2009 03:53:01 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-75-22.phlapa.east.verizon.net [141.151.75.22]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 9FBBE6D4DB; Mon, 23 Mar 2009 12:52:59 +0900 (JST) Date: Sun, 22 Mar 2009 23:52:53 -0400 From: Yoshihiro Ota To: Robert Watson Message-Id: <20090322235253.432874dd.ota@j.email.ne.jp> In-Reply-To: References: <20090320045319.04484fc5.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 03:53:02 -0000 On Fri, 20 Mar 2009 13:24:09 +0000 (GMT) Robert Watson 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. Thanks, Hiro