Date: Wed, 25 Mar 2009 00:59:11 -0400 From: Yoshihiro Ota <ota@j.email.ne.jp> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good Message-ID: <20090325005911.87aa63ab.ota@j.email.ne.jp> In-Reply-To: <alpine.BSF.2.00.0903230816530.85640@fledge.watson.org> References: <20090320045319.04484fc5.ota@j.email.ne.jp> <alpine.BSF.2.00.0903201321570.48549@fledge.watson.org> <20090322235253.432874dd.ota@j.email.ne.jp> <alpine.BSF.2.00.0903230816530.85640@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Mar 2009 08:20:20 +0000 (GMT) Robert Watson <rwatson@FreeBSD.org> wrote: > > 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. Actually, the programs I had problems with were ggated/ggatec. As I look back my records, I found a problem with ggate when I had a slow ggated server (Celeron 400MHz) and a fast ggatec client (AMD Turion(tm) 64 X2 1.9GHz). While the client was writing a large file to the server, there were often major delays in its communication. While this was happening, I observed with "systat -vm" and saw interrupts on the NIC was 1 per a couple seconds. Indeed, I tested SCTP with ggate but as far as I remember, STCP seemed to have problems such that ggate couldn't establish a connection back in 7.0-RELEASE. I tested the same code in 7.1-RELEASE just before and it appeared to be working. It was just an experiment back in a year ago and couldn't find a reason easily. So, I gave up. Recently, ggate became necessity. I enhanced some of debug capabilities and found that when this happens, sequence numbers in ggate are out of sync. For example, while this is happening, ggatec reports it has finished send() with seq# 186, but at the same exact time, ggated reports it has only recv()ed up to seq# 184. They get synced eventually, but it takes long time and happens frequently. Meanwhile, terminal does not response in timely manner. This hiccup doesn't happen if client is doing read-access to ggated. FTP or nfs doesn't have similar hiccup and communicate at its max speed, 100-Base T. Both ggatec and ggated creates 2 TCP connections and 2 threads for blocking reads and writes. When I mentioned this problem to the friend mentioned above, he suggested to change 2 uni-directional TCP connections to 1 bi-directional one. In fact, this fixed the problem. At the same time, he also expressed that 2 uni-directional TCP connection was so bad no one should not use like it must be prohibited at all. So, I wondered and wanted to know how other people would say about it. If using 2 uni-directional TCP communication is not that bad idea or something prohibited, then we may have some issues in TCP layer. If anyone is interested in looking into, I can elaborate other observations as well. Thanks, Hiro
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090325005911.87aa63ab.ota>