0

I'm stumped by a very strange behavior on my machine.

Trying to port a Remoting application to WCF I wanted to implement a "one proxy per server call" scheme (like proposed here).

I went for a standard net.tcp binding and noticed that the first (and now, only) call for each proxy was incredibly slow: opening the client channel took about 2 seconds!

At first I thought it's because of the default transport security for net.tcp bindings, but switching to Security.None didn't bring any improvement.

After lots of tests I found out that basicHttp binding was about 1000 times faster: opening the channel took about 2 ms!

Then I tried playing around with the service URI. For my tests both server (self hosted) and client were on the same machine (in fact even in the same process).

In the beginning I used "net.tcp://localhost:Port/..." and got 2 seconds for opening the channel.

Just out of curiosity, because I'm working over an RDP connection via VPN, I tried my machine's explicit hostname "net.tcp://myworkmachinehost:Port/..." and now it took 4 seconds to open the channel!

Finally I tried avoiding name resolution and used "net.tcp://127.0.0.1:Port/..." and suddenly everything was blazing fast: Opening the channel took a mere 2 ms!

A colleague of mine got the same 2 second delay with "localhost" on his machine (not working from remote). Using his hostname also gave 2 seconds and using the IP address was fast as well.

With basicHttpBinding there's no performance difference in how we specify the service URL.

Calling "nslookup myworkmachinehost" immediately returns my IPv4 address, so name resolution itself also seems to be fast.

Apart from modifying the server address on client side I also tried all possibilities with the server with very strange results.

  • Server endpoint address net.tcp://0.0.0.0:Port...

    • Client URL 127.0.0.1:Port: 6 ms
    • Client URL localhost:Port: 2005 ms
    • Client URL myworkmachinehost:Port: 4007 ms

  • Server endpoint address net.tcp://127.0.0.1:Port...

    • Client URL 127.0.0.1:Port: 6 ms
    • Client URL localhost:Port: 20135 ms
    • Client URL myworkmachinehost:Port: TIMEOUT after 10 s

  • Server endpoint address net.tcp://localhost:Port...

    • Client URL 127.0.0.1:Port: 5.5 ms
    • Client URL localhost:Port: 1.5 ms
    • Client URL myworkmachinehost:Port: 1 ms

  • Server endpoint address net.tcp://myworkmachinehost:Port...

    • Client URL 127.0.0.1:Port: 8 ms
    • Client URL localhost:Port: 2 ms
    • Client URL myworkmachinehost:Port: 1.5 ms

How can this be and what can I do to further analyze this situation?

Thanks in advance...

mav
  • 85
  • 11
  • I think this is because these addresses have different meanings. For example, 127.0.0.1 is usually assigned to "loopback" or local interface only IP address. 0.0.0.0 means listening on each available network interface. But in general, if the client address is the same as the server address, the channel creation time should be the shortest. – Ding Peng Jun 26 '20 at 08:25
  • Yes, the addresses have slightly different meaning. The initial try (0.0.0.0) was the one I wanted for the server: Listen to all interfaces/IP addresses. But this gives this unacceptable 2 seconds delay on first call. – mav Jun 26 '20 at 13:11
  • As I said above, when the URI of the client is the same as the URI of the server, the time consuming should be the shortest. – Ding Peng Jul 01 '20 at 09:47
  • I really don't want to write the server's name or IP address to the server-side configuration file as this will make deployment a nightmare. The client can be configured to access different servers and you're free to use a name or ip address there, but the server can only host the service on his own machine. For the moment I've settled for using localhost:port on the server side, but I still think it's a bug to get 2 second delay when using 0.0.0.0 in the server configuration's address. – mav Jul 01 '20 at 14:07

0 Answers0