Date: Fri, 20 Mar 2009 01:56:56 -0700 From: Michael David Crawford <mdc@prgmr.com> To: Yoshihiro Ota <ota@j.email.ne.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good? Message-ID: <49C35A58.2030607@prgmr.com> In-Reply-To: <20090320045319.04484fc5.ota@j.email.ne.jp> References: <20090320045319.04484fc5.ota@j.email.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Yoshihiro Ota wrote: > I saw a program that opens 2 TCP connections. > One connection is only used for server to client messaging only > and the other connection is used only for client to server messaging. > 2. He also said that it would also waste network bandwidth. You have a two-way communication no matter what you do. But if you don't actually use inbound direction, all it gets used for is the receipt of ACK packets. That is, the inbound connection is used to make the data transfer reliable. If you don't have any payload data on the inbound connection, then the outbound connection won't have any ACK packets. If you're sending payload data, the ACK info can "hitchhike" along with the payload packets, thus saving bandwidth. But if you're not sending any payload data at all, there will be packets transmitted which contain the ACKs and nothing else. The extra network overhead will be modest if you're sending a lot of data all at once, say transferring a large file. But if very little data is sent per packet, say individual characters in a telnet connection, the overhead would be very high. If you have a single connection with payload data in both directions, then the ACKs will almost always ride along with some payload data. The only time a packet will contain nothing but an ACK will be when some data was transmitted, but none is to be received at the time. Mike -- Michael David Crawford mdc@prgmr.com prgmr.com - We Don't Assume You Are Stupid. Xen-Powered Virtual Private Servers: http://prgmr.com/xen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C35A58.2030607>