IMHO it's superfluous and it wastes resources (network ports).

What problems does it avoid?  What benefits do you see?

Depending on which party opens up the connections this approach might
create additional problems (firewalls).

Kind regards

    robert

Off hand I can't see any advantages to doing it this way. What
problems are you avoiding?

It's certainly more complicated to set up two sockets than one.

There is a slight performance disadvantage of using a socket in one
direction, due to the fact that e.g. ACK can't be piggybacked onto
data in the reverse direction when there isn't any.

Handling errors on just one of the connections becomes more
complicated than necessary when you also have the second connection to
deal with.

/gordon

On Tue, 11 Apr 2006 14:24:58 +0200, Andersen
<andersen_800@hotmail.com> wrote, quoted or indirectly quoted someone
who said :

You can use separate threads to write and read sides of the same
socket.  You don't need two different sockets for that.

The only reason I can see to use two socket connections would be to
separate a command/response channel from a (bidirectional) data pipe,
and even then its usually not necessary unless there are stringent
performance requirements.

The main problem when one server is handling many clients (the general
case) is that you'll need to implement some mechanism to guarantee that
the second connection of a pair is recognized as belonging to the
correct client. Preferably the second connection is also opened by the
client because this is easier to handle if there is a firewall or proxy
between the client and server. Another possible issue is that you may
have a second type of client that controls and monitors the server: this
probably *doesn't* want to open a second connection, so your server must
distinguish between the two types of client.

I've been trying to think of problems that it avoids, but so far haven't been
able to...

What do you see as the problems ?

   -- chris