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