5

I was wondering,

1st question What are the pros and cons of using one socket (full duplex) vs. two socket (simplex) per peer: one for read and other write? Specially in terms of performance and resource utilization.

2nd question In case, if i choose to use more than 1 sockets per peer, on all i do read and write. Then will it helps me scale out in handling no of messages handled?

3rd question: what should help me determine the number of sockets per peer? Network Bandwidth? No. of message in and out?

All questions are different and do not have any inter-relation.

Abhishek Jain
  • 9,614
  • 5
  • 26
  • 40
  • What's kind of application uses that socket(s)? If you need different kinds of communications in parallel, you had to use two sockets like FTP. – Fumu 7 Sep 04 '14 at 05:28
  • 1
    Some proprietary protocol sending and receiving messages over TCP sockets. – Abhishek Jain Sep 05 '14 at 06:06
  • 2
    One drawback of using two sockets is the added complexity. With a single socket, the socket is either connected or it isn't. With two sockets, now you have to figure out how to handle it when one of the two socket connections has been broken (or failed to connect) while the other is still connected. It's extra hassle, for no clear benefit. – Jeremy Friesner Sep 05 '14 at 06:45

2 Answers2

5

What are the pros and cons of using one socket (full duplex) vs. two socket one for read and other write? Specially in terms of performance and resource utilization.

Pro one socket: resource utilization. Contra one socket: nil. Performance: identical, except that you save on connect and close handshakes if you only use one socket.

In case, I choose to take two socket approach, then will not be useful to use both of them full duplex, that way it helps me scale out in terms of data flowing in and out?

Now you're comparing apples and oranges. You can't compare one full-duplex socket with two full-duplex sockets. I don't know why you think you might need two inbound and two outbound flows, but you don't. Every protocol I can think of except FTP uses only one.

what impact does network bandwidth has on it?

Nil.

or it has on network utilization?

Nil, apart from the connect and close handshakes. But it wastes resources at both ends.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Sorry, i was not able to write the questions well. 2nd question is different from the 1, they are not inter-related. What i wanted to know in 2nd question is, if i choose to use two sockets per destination, on both i do read and write. Then it helps me scale out in handling no of messages. 3rd question was choosing number sockets per destination, should depend on available bandwidth? – Abhishek Jain Sep 05 '14 at 06:00
  • The answer to the second question depends on your functional requirements. I don't see how it helps to scale anything. The answer to the third question is no. – user207421 Sep 05 '14 at 06:14
  • @EJP just to play devil's advocate (since I also think two sockets is one socket too many)... what about the case where a TCP packet is dropped? In the one-socket case, your entire data flow in that direction will pause (briefly) until the dropped packet gets detected and resent. With two sockets, you could continue receiving data from the other socket during that period, as TCP stream B would be unaffected by a packet dropped from TCP stream A. – Jeremy Friesner Sep 05 '14 at 06:51
  • @JeremyFriesner Of course, if your functional requirements so indicate. Mostly they don't. Mostly they require that you do client-side things serially rather than in parallel. – user207421 Sep 05 '14 at 07:08
  • If latency is large, like communication between U.S. and europian country, and many requect-response communication is necessary, and most of request-response communications are independent, increase number of sockets may help to increase message handling ability in general. If if use 10gb/s network and sending large packets, one socket is enough, because data bandwidth of hard disk limits the speed of data transmission. – Fumu 7 Sep 05 '14 at 08:31
  • The applications are peer applications running within a local network primarily. Both the applications can be consumer as well as provider i.e. both can request to each other and may/may not expect a response. The requests does not have to serialized. – Abhishek Jain Sep 05 '14 at 14:38
  • @Fumu. I have no idea why you are asking me those questions. It's not my application. I also have no idea why you think more sockets 'may help to increase message handling ability'. If you have a reason for this apparent snake-oil belief please state it. – user207421 Feb 27 '19 at 21:26
2

We've added --full-duplex to iperf 2.0.14 which will test a full-duplex socket. One can dompare it to two sockets per the -d or --dualtest option. We've found "your mileage will vary" and there is no universal to answer of having equal performance or not. In theory, it seems they should be equal but, in practice, maybe not.

   -d, --dualtest
          Do a bidirectional test simultanous test using two unidirectional sockets

       --fq-rate n[kmgKMG]
          Set a rate to be used with fair-queueing based socket-level pacing, in bytes or bits per second. Only available on  platforms  supporting  the  SO_MAX_PACING_RATE  socket  option.
          (Note: Here the suffixes indicate bytes/sec or bits/sec per use of uppercase or lowercase, respectively)

       --full-duplex
          run a full duplex test, i.e. traffic in both transmit and receive directions using the same socket

Bob

rjmcmahon
  • 324
  • 1
  • 3