In article <1141336756.033668.74080@t39g2000cwt.googlegroups. com>,
"Druid" <mattdruid@gmail.com> wrote:

> A TCP connection can send and receive over the same connection, but
> is there a benifit to creating two TCP connections? I was thinking of
> using one specifically for sending, and one specifically for receiving.
> In what cases, if any, would you want to use two? This might be a
> newbie question, but I've been unable to find an answer about it yet.

I don't think there would be a significant benefit. If you use one
connection, ACKs can be piggy-backed on data segments, so you may get
slightly better performance this way.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
> "Druid" <mattdruid@gmail.com> wrote:
>
> > is there a benifit to creating two TCP connections? I was thinking of
> > using one specifically for sending, and one specifically for receiving.
> > In what cases, if any, would you want to use two?

> I don't think there would be a significant benefit. If you use one
> connection, ACKs can be piggy-backed on data segments, so you may get
> slightly better performance this way.

In the case of bidirectional data flow, Barry is correct (no surprise
there) that if anything, using a single channel might provide better
performace.

....With one gotcha: Certain buggy TCPs have a problem digging
themselves out of congestion control. When cwin is throttling
transmission, an incoming ACK with a payload (LEN > 0) is misfiled as a
DUPACK.

If your application is heavily bidirectional, and the connection
suffers some packet loss, the throughput will never recover because of
this bug.

Most applications are not heavily bidirectional, so that problem is not
widely observed.

There's another reason an application might want to use two sockets,
but not for bidirectional traffic: Unidirectional data flow over a
lossy network will probably be faster with several parallel sockets
than with one big one.

Non-high performing TCPs are too considerate and won't allow a single
socket connection to push the network hard enough. Parallel
connections will find the absolute limit (ever have to coexist with
edonkey?)

/chris marget

Well, the application isn't heavy bidirectional, it will be really
heavy in one direction, and light in the other. I want to guarantee
that the light direction doesn't suffer from any starvation if the
other direction is under heavy load.

I'm not concerned about the ACKs, I'm not sure if I should be.

So, would having two dedicated TCP connections (4 ports total - 2
endpoints on each side) in my application, 1 for sending, 1 for
receiving, would improve performance and mitigate starvation given this
context? From what you've said so far, it doesn't sound like it.

I'd just go ahead and use one socket/connection. Be certain to
provide all "logically associated" data to the transport in one call
(writev, sendmsg etc).

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <1141657940.031014.318260@u72g2000cwu.googlegroups .com>,
"Druid" <mattdruid@gmail.com> wrote:

> Well, the application isn't heavy bidirectional, it will be really
> heavy in one direction, and light in the other. I want to guarantee
> that the light direction doesn't suffer from any starvation if the
> other direction is under heavy load.

It shouldn't be a problem. The two directions are effectively
independent. Implementations don't usually share any per-connection
resources between the two directions, so there's nothing to starve
(there may be some system-wide resources that are shared, but then the
starvation would affect separate connections just as much as a single
connection).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article <barmar-23B8CD.19491306032006@comcast.dca.giganews.com>,
Barry Margolin <barmar@alum.mit.edu> wrote:

>> Well, the application isn't heavy bidirectional, it will be really
>> heavy in one direction, and light in the other. I want to guarantee
>> that the light direction doesn't suffer from any starvation if the
>> other direction is under heavy load.
>
>It shouldn't be a problem. The two directions are effectively
>independent. Implementations don't usually share any per-connection
>resources between the two directions, so there's nothing to starve
>(there may be some system-wide resources that are shared, but then the
>starvation would affect separate connections just as much as a single
>connection).

Starvation can happen in the application as well as the operating system
or network machinery. For example, an application I care about involves
systems doing what might be described as flooding database changes to
peers and expecting peers to respond with grouped "commits." Things are
symmetric. Each system would rather not have incoming commits mixed
with and so delayed by the far larger database changes in a single TCP
pipe. The commits from a peer are relatively rare, and far quicker and
easier to handle that database changes. For various reasons incoming
commits should have higher priority than incoming database change
requests. My solution is two TCP connections between each pair of
peers. Each system handles incoming database changes only after it
has attended to incoming commits.

Of course, if you need to ask in a newsgroup to hear what's been said
in this thread, the right answer is almost certainly "one socket."


Vernon Schryver vjs@rhyolite.com

In article <duitka$30bu$1@calcite.rhyolite.com>,
vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

> In article <barmar-23B8CD.19491306032006@comcast.dca.giganews.com>,
> Barry Margolin <barmar@alum.mit.edu> wrote:
>
> >> Well, the application isn't heavy bidirectional, it will be really
> >> heavy in one direction, and light in the other. I want to guarantee
> >> that the light direction doesn't suffer from any starvation if the
> >> other direction is under heavy load.
> >
> >It shouldn't be a problem. The two directions are effectively
> >independent. Implementations don't usually share any per-connection
> >resources between the two directions, so there's nothing to starve
> >(there may be some system-wide resources that are shared, but then the
> >starvation would affect separate connections just as much as a single
> >connection).
>
> Starvation can happen in the application as well as the operating system
> or network machinery. For example, an application I care about involves
> systems doing what might be described as flooding database changes to
> peers and expecting peers to respond with grouped "commits." Things are
> symmetric. Each system would rather not have incoming commits mixed
> with and so delayed by the far larger database changes in a single TCP
> pipe. The commits from a peer are relatively rare, and far quicker and
> easier to handle that database changes. For various reasons incoming
> commits should have higher priority than incoming database change
> requests. My solution is two TCP connections between each pair of
> peers. Each system handles incoming database changes only after it
> has attended to incoming commits.

This sounds like a very different issue -- you're talking about two
connections for the *same* direction, or for different types of
communication (e.g. FTP's Control and Data connections). The OP was
specifically asking about whether to use separate connections for the
opposite directions.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 2006-03-07, Barry Margolin <barmar@alum.mit.edu> wrote:

> This sounds like a very different issue -- you're talking about two
> connections for the *same* direction, or for different types of
> communication (e.g. FTP's Control and Data connections). The OP was
> specifically asking about whether to use separate connections for the
> opposite directions.

Thinking back in this thread to using a single TCP socket instead of
multiple ones for performance, this thread reminds me of the URG
flag in TCP, and how (from my own experience) this was never quite used
or implemented in a useful way and how it might have ed out moving
control elements of a communication faster than content.

Does anyone remember / recall / have an opinion on what happened to
the use of the URG bit?

/dmfh

----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

In article <slrne128gf.l1l.dmfh@llanfaethlu.dmfh.cx>, DMFH <dmfh@n0spam.dmfh.cx.spamn0t> writes:
>
> Thinking back in this thread to using a single TCP socket instead of
> multiple ones for performance, this thread reminds me of the URG
> flag in TCP, and how (from my own experience) this was never quite used
> or implemented in a useful way and how it might have ed out moving
> control elements of a communication faster than content.

(The following is assuming I'm remembering the semantics of URG
correctly; I'm on a trip and don't have all my resources handy. No
doubt I will be corrected where I'm wrong.)

Urgent data doesn't get delivered to the receiving host any faster -
it's just an indication that there's special (notionally out-of-band)
data further ahead in the stream. "Further ahead" is allowed to be
after the data that's in the packet with URG set, but the receiver
still has to receive the intervening data.

> Does anyone remember / recall / have an opinion on what happened to
> the use of the URG bit?

Well, having differing interpretations of the Urgent Data offset
field in various implementations didn't . Some discussions on
the TCP-IMPL list have also suggested that some of the assumptions
made about urgent-data handling in RFC 1122 weren't obvious to all
implementors. See for example the thread starting at

http://tcp-impl.grc.nasa.gov/list/archive/0764.html

which has some interesting discussion of URG handling.

One point which occurred to me reading these discussions: the
consensus seems to be that as soon as the sender tries to send urgent
data, the next outbound segment should have the URG flag set, even if
it doesn't contain any of the urgent data because more in-band data
is waiting to be sent than can fit in the segment / receiver's
window. However, presumably this can only be done if there's no more
than 64KB of data in front of the first OOB octet, because the Urgent
Pointer field is 16 bits.

Though on reflection maybe that's not possible, because TCP will
block the application's send operation, or in non-blocking mode
refuse to queue more outbound data, if the application tries to send
more than the receiver's window, which would prevent the sender from
queuing up lots of outbound normal data followed by OOB data. I
think.

--
Michael Wojcik michael.wojcik@microfocus.com

Don't forget your fighting spirit at each balls you pitch!
-- Tornado Boy Volunteer Staff International