2

I have an asynchronous console .NET socket client application that establishes dozens of connections to a remote socket server.

It's a stress test application so each connection sends as many messages as possible waiting for an acknowledgement from the remote server after each message gets sent.

The socket server has a public IP but I can also use the internal IP because it's in the same network.

As the number of connection increases the number of messages per minute goes down pretty bad and I've been trying to find out why.

But for some reason, the performance only seems to go down for the connections sharing the same destination IP. In other words, if I connect 100 users to the internal IP and 5 users to the external IP, the latter get top-notch performance while the former suffer.

But this makes no sense because all the communication is happening exactly between the same two machines (my desktop and the one-and-only server).

The amount of data being transferred doesn't seem that high for it to be some kind of network flooding. Honestly, it looks like some sort of artificial cap for the number of simultaneous sockets waiting for answers on a given destination IP. I've profiled my code and that's where it hangs, waiting for the remote server to answer. Is there a setting like that somewhere in the config files for .Net?

UPDATE: there's just one NIC in the server, the external IP we use to reach it works via port forwarding.

More internal IPs were added to the server but they ended up competing with each other for resources i.e. only the external IP is behaving differently. This makes me suspect the bottleneck is on the server side, maybe some kind of load balancing per client IP (when we connect via external IP the client IP they receive would be different as well)

royalstream
  • 143
  • 7
  • 1
    When you say it has an "external ip" what do you mean exactly? There are many ways to configure that. Port forwarding on the external firewall, or the server itself might have two nic's with two network cables going to two different switches, one internal and one external.... in which case it would explain your results since you would have 2x the bandwidth. – Erik Funkenbusch Aug 21 '14 at 02:24
  • 1
    The TCP protocol itself with throttle back as the pipe becomes full. Is this the issue. Are you using the IO completion port API or the older one? UDP example of ReceiveFromAsync: http://stackoverflow.com/questions/18483836/cause-of-high-udp-package-loss-on-localhost/18513956 – Brannon Aug 21 '14 at 03:31
  • @ErikFunkenbusch according to their IT guy they're only using one nic but I'll verify it myself. – royalstream Aug 21 '14 at 21:03
  • @Brannon that's very very interesting. I'm giving it a try right away. – royalstream Aug 21 '14 at 21:58
  • @royalstream - If they're putting two IP's on a single nic for both internal and external use, then they should be fired. That's highly insecure. You can certainly put more than on IP on a NIC, but when they are different networks, and one is external like that.. it's a huge no-no. – Erik Funkenbusch Aug 21 '14 at 22:19
  • @ErikFunkenbusch they are using port forwarding, I don't think the single nic has both IPs. I wonder if there's any kind of "load balancing" going on. When I use the internal IP the server is going to receive the requests directly from my desktop's IP (as opposed to the forwarded requests). – royalstream Aug 21 '14 at 22:43
  • @Brannon your suggestion did improve the performance significantly. It definitively looks like that was part of it. But I still get better performance when I put a handful of connections using a different destination IP, even if they use the old completion api. – royalstream Aug 21 '14 at 22:46
  • @royalstream - This is the problem with not providing code.. you use terminology that is inaccurate and assumptions have to be made. Without code to see what is actually happening, all we can do is guess. – Erik Funkenbusch Aug 22 '14 at 02:51
  • @ErikFunkenbusch my code now matches the bottom snippet found in Brannon's link http://stackoverflow.com/questions/18483836/cause-of-high-udp-package-loss-on-localhost/18513956 – royalstream Aug 22 '14 at 03:04
  • FWIW, I've improved my code in the link since I posted it. I no longer recreate the SocketAsyncEventArgs for every call. I only create it once, set the buffer once, and reuse it (passing it in on the very first call). – Brannon Aug 22 '14 at 15:12

0 Answers0