0

I have a duplex voice and video chatting service hosted in IIS 7 with netTcpBinding. The consumer of the service is a Silverlight client. The client invokes a method on the service: SendVoiceAsync(byte[] buffer) 10 times a second (every 100ms), and the service should call the client back also 10 times a second (in resposnse to every call). I've tested my service rigorously in a LAN and it works very well, for every 100 calls sending the voice/video buffer to the service, the service calls the other clients back 100 times with received voice buffers in that time period. However when I consume the service over the internet it become horrifically slow, lags terribly and often gives me a timeout error. I've noticed that over HTTP the callbacks are being received at a rate of about 1/10th of each call to the server, so for every 100 calls to the service, the server calls the clients back 10 times, when this number should be 100 (as it is in LAN) or something very close to it.

So what could be causing the service to become so laggy over HTTP? I've followed the general guidelines on configuring netTcpBinding for optimised performance, and while it seems to pay dividends in LAN its terrible over the internet. It feels as if something is blocking the client from sending their replies to the service, though I've disabled all firewalls, and forwarded ports 4502-4535 and port 80 on which the website hosting the service resides to the server computer. If it helps, my service has ConcurrencyMode set to Multiple, and it's InstanceContextMode set to Single. Also my service operations are all one way and not request-reply.

Thanks for any help.

Mohammad Sepahvand
  • 17,364
  • 22
  • 81
  • 122
  • HTTP? netTcpBinding? I don't think so. Anyway... You should try to write a simple socket test program to see what the raw perf of of your link is. – tzerb May 28 '12 at 19:28
  • you mean netTcpBinding over HTTP is just a bad idea? – Mohammad Sepahvand May 28 '12 at 19:29
  • netTcp is a binary protocol. How are you using HTTP? – tzerb May 28 '12 at 19:30
  • I have my service hosted as an application inside a website in IIS 7. I'm then able to add references to the service across the internet with my public IP. I've done this before (netTcp over HTTP) for services which have a lesser load (getting data from a database and sending it out over on the internet)....and to my experience if you forward the right ports in your router, it usually works. – Mohammad Sepahvand May 28 '12 at 19:33
  • yeah, I've never heard of it. I'm going to assume you mean you used netTcp when you were testing locally but converted to some http binding when you went to deploy. So your real question is probably "Why is my performance so bad when I try to send twice as much data into a link with a fraction of the capacity." – tzerb May 28 '12 at 19:41
  • Have a look [here](http://stackoverflow.com/questions/1590973/wcf-nettcp-binding-over-internet) and [here](http://social.msdn.microsoft.com/Forums/eu/wcf/thread/740fdf69-98f9-4ac4-b25e-00aa5e5763ed). Sorry, but I still don't quite get your point? I've compressed my audio and video very heavily, from tests we did in a LAN the incoming and outgoing traffic into the server was 80 kBps when 5 people were conferencing, that equates to a standard 512kB internet connection. So what exactly is your point about over going the "link's" (assume you mean the service by that) capacity? – Mohammad Sepahvand May 28 '12 at 19:50
  • I'm sorry I can't help you. I recommend reposting the question with exacty the code/config you're using. – tzerb May 28 '12 at 20:01

1 Answers1

1

The internet is a much more noisy and difficult network than LAN: packets might get lost, re-routed via different routers/switch and the latency is generally pretty bad.

That's why TCP exists, it is an ordered, reliable protocol so every packet is acknowledged by the receiver and re-sent if it didn't make it.
The problem with that is it does not try to be fast, it tries to get all of the data sent across and in the order it was sent.

So I'm not surprised that your setup works in LAN, as LAN Round Trip Times (RTT) are usually about 5 ~ 80 ms, but fails over the internet where an RTT of 250 ms is normal.

You can try to send your data less often, and switch to UDP which is non-ordered and unreliable but faster than TCP. I think UDP is standard for voice/video over the internet as you can compensate for the lost packets with a minor degradation of the voice/video quality.

Online games suffer from the same issue, for example the original Quake was unplayable over the internet.

Julien Lebot
  • 3,092
  • 20
  • 32