1

I have browsed the internet and stack overflow for answers but I can't seem to get a clear answer to my issues.

I have around 50 clients spread out across the country that regularly open up a WCF WSHTTPBinding call automatically through a Windows service to the server every 10-20 mins. This works well because I limit the # of clients that can connect and perform long running operations through the server and the client then knows it cannot do anything and tries the next time it checks back in.

This has been working well until yesterday when one client that has 7 separate systems behind the same router started having very very slow internet issues. So those 7 systems would open up a connection to the server every 10-20 mins, and perform their "check-in" procedures. The calls would take a while and each system may be connected to the service at once using up 7 connections to the server. The other 43 systems also need to "check-in" as well every 10-20 minutes. But since the client with 7 systems was having slow internet, the calls to the long running processes on the serice were taking longer than normal and eventually timing out on the client (I even got stale security timestamp errors sometimes). This in return would occasionally hang the WCF service from responding to any other client requests and then eventually the client would timeout and the server connections would clean up and process other requests.

I need my service to be completely unaffected by client internet issues and the service needs to keep chugging along servicing the other clients that continue to "check-in".

Now, I've implemented Service Throttling Behavior on the service end already:

Dim stb As New ServiceThrottlingBehavior
stb.MaxConcurrentSessions = 100
stb.MaxConcurrentCalls = 20
stb.MaxConcurrentInstances = 120

serviceHost.Description.Behaviors.Add(stb)

I've done some reading out there and found this setting, but do not have this in my code as of now:

System.Net.ServicePointManager.DefaultConnectionLimit

Which I've tried to understand but don't entirely. So, now with my explanation, here are my questions:

  • Do I set System.Net.ServicePointManager.DefaultConnectionLimit at the service or client end?
  • Where would I set that? Before I open the ServiceHost? Before I create the ServiceHost?
  • Are there any other areas to change for connection limits and concurrent calls for WCF? (It seems from my reading there can be a few, depending on what binding you're using)

Note: If you post answers, please use code, I do not use the config file for my bindings, I create my binding programmatically.

Thank you.

ScottN
  • 1,490
  • 2
  • 20
  • 34

1 Answers1

0

I don't understand what your service is doing that 'slow internet' should affect it. Are you sending massive amounts of data back and forth every check-in? Without some more detail on the design it's hard to say just what is going on.

That said, I do think you should look at the design again. If the server is doing a really long running operation before it can respond to the client, the client shouldn't just hang around and wait for it over HTTP for 10 minutes at a time. It would make more sense to send the request, then either check back occasionally to see if its done (and not be required to hold a connection) or use net.tcp as your binding and use something that's more suited to holding such lengthy connections (net.tcp could also use a callback to notify the client when the call is done).

Tridus
  • 5,021
  • 1
  • 19
  • 19
  • Yes, large amounts of data are being transferred to server from client, so there is an "upload" of data from an internet connection that if slow, will keep the connection open and will eventually timeout. So, the design is there and works, its a connection limit issue. Which part of my questions are regarding DefaultConnectionLimit and how to implement it. – ScottN Feb 11 '11 at 22:13
  • If you're sending a lot of data, using Streamed transfers might work better. The way IIS handles those in my experience, it won't even get to WCF until the data has been streamed up. – Tridus Feb 11 '11 at 22:24
  • I agree I could re-visit the design but for immediate solution to the clients "holding up a connection" because it is uploading the data slowly to the server I would love to know how to implement more flexibility into the server to accept more connections at once. From what I've read, 10 is the limit. So if 6-7 are taking up connections, it doesn't take many more from the other 43-44 clients to reach that max connection limit. – ScottN Feb 11 '11 at 22:27
  • 10 is the session limit, but you're increasing that. According to this, you might try turning off sessions entirely to get around that limit: http://www.dotnetconsult.co.uk/weblog2/PermaLink,guid,af6e6325-2e30-42e3-acb9-57e1363fa51e.aspx – Tridus Feb 11 '11 at 23:47
  • I'm thinking of implementing NetTCPBinding and slowly moving clients over to that. It seems there may be some wsHTTPBinding limitation that can't be changed.. at least from what I understand. What are your thoughts? http://stackoverflow.com/questions/832871/wcf-concurrent-requests-piling-up-on-the-server-when-using-wshttpbinding – ScottN Feb 14 '11 at 16:23
  • I don't have a specific answer because I don't have a lot of experience with wsHttpBinding. I try to avoid it because it's so complicated that a lot of weird stuff can go wrong. I do think based on the length of the operations you're doing that net.tcp would be a better binding, as it's meant for extended or always-on connections. It'll probably be faster too! – Tridus Feb 14 '11 at 18:50