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>