3

I am developing live chat using SignalR. It is great library. But i coped with one problem that I cant resolve for some time. So problem in when signalR made 8-10 connections at a time live chat doesn't work any more. Maybe it is b/c i run everything on local machine?

I thought maybe I made mistake somewhere. So I found simplest chat. You can download it here. I opened it in 10 windows and it dont work anymore. Is that performance issue of signalR or programmers mistake? How can i make it work faster?

Also I found JabbR chat . And it has live demo and it works for a lot of people. They dont make anything special and it work greatly.

Can someone help with this issue?

Great thanks for any help, Dima.

Ramesh
  • 13,043
  • 3
  • 52
  • 88
F0rc0sigan
  • 676
  • 2
  • 11
  • 22
  • In which web server you are testing? – Ramesh May 03 '12 at 06:48
  • I am developing .net application so i use Development ASP.NET Server. – F0rc0sigan May 03 '12 at 09:32
  • 1
    The problem could be that max concurrent connections is reached. Try using iis express – Ramesh May 03 '12 at 09:47
  • Runned in vs 2011 that is always use IIS Express. The same problem. I open 10 tabs not more. How can 10 tabs reach 5000 concurrent connections that are set by default by ASP.NET. Maybe i can try anything else? – F0rc0sigan May 03 '12 at 10:54
  • What do you mean by Live chat doesn't work any more? You get exceptions or any errors logged? What is the health of your application? – Ramesh May 03 '12 at 10:57
  • I dont get any errors. Just signalR sends ajax request and it dont come to server. It can come in few minutes. It is куфддн strange. – F0rc0sigan May 03 '12 at 11:00
  • It might be the maximum number of connections to one host address has been reached in the browser. Try using 2 different browsers. – ZippyV May 03 '12 at 12:20
  • I faced with the same problem and described it here: http://stackoverflow.com/questions/9946951/signalr-server-doesnt-receive-any-requests-if-more-than-x-connections-establis If different browser are opened - there's no issue. Seems the limit is per browser, cuz i get different numbers for different browsers. – Jan Lobau Oct 25 '12 at 10:24
  • @F0rc0sigan hey I am facing the same issue. What worked for you finally? – Yasser Shaikh Dec 19 '16 at 08:32

2 Answers2

5

There are two problems you might have ran into:

  1. IIS/Cassini on Windows 7 has a default limit of 10 concurrent connections. Try running tests on Windows Server and see if it behaves the same.
  2. Try opening the connections in separate browser windows and/or separate browsers and/or machines, not tabs. I noticed that in 0.4 things can mess up when using tabs.
Piotr Szmyd
  • 13,371
  • 6
  • 44
  • 61
  • 1
    You can use iis express on windows 7 as well. It doesn't have those limits. – davidfowl May 07 '12 at 14:27
  • @davidfowl , i am having this issue only when i open more than one tab, but inside one tab it was working pretty fine . can u please give me some information regarding this , thanks – Sajjad Ali Khan Apr 25 '17 at 06:07
  • 1
    When you're not using websockets, there's a limit in the number of concurrent connections you can have open to a particular hub. – davidfowl Apr 25 '17 at 06:21
  • i enabled the websockets for IIS and also i increased the concurrent Requests to CPU inside aspnet.Config file , then also i am facing same issue . When i check the Fiddler, the request is not reaching server , it gets freezed(not getting any response) . the url looks like this http://localhost/Microcare/signalr/start?transport=webSockets ..... – Sajjad Ali Khan Apr 25 '17 at 08:45
0

Found how to workaround:

Rewrite connectionId, so in every tab you'd have the same sonnection id:

 public class MyConnectionFactory : IConnectionIdGenerator
    {
        public string GenerateConnectionId(IRequest request)
        {
            return MyUserManager.Instance.CurrentUserID.ToString();
        }
    }

Add to global.asax:

GlobalHost.DependencyResolver.Register(typeof(IConnectionIdGenerator), () => new MyConnectionFactory());

And I managed to open as mach tabs, as I could. And all tabs get notifications.

Hope, that helped.

Dmitry
  • 661
  • 5
  • 21
  • 1
    I don't think so. Connection IDs need to unique per connection or everything breaks down: http://stackoverflow.com/questions/11522090/signalr-how-is-a-duplicate-connection-id-handled – Alexander Köplinger Oct 22 '12 at 12:17
  • I tested this, on Chrome and FF opened under the same ConnectionId, with several opened tabs, and every tab gets notifications from signalR. If you could explain, when I have to expect problems? 'cos I'm going to stay with this workaround, 'cos it works for now.. Thank you. – Dmitry Oct 22 '12 at 12:29
  • In my tests, using the same connection id for multiple connections (like when you open multiple tabs or browser windows) results in getting disconnected immediately. It might be a side-effect of the Server-Sent-Events transport used in Chrome and FF if this doesn't happen to you. As dfowler (the creator of SignalR) mentions in the question I've linked, connection ids must be unique. This is also the reason why he removed `IConnectionIdGenerator` from the upcoming version of SignalR, so generating duplicate ids is impossible. – Alexander Köplinger Oct 22 '12 at 15:25
  • Then, it means, that we cannot use SignalR, if a user opens several tabs?.. I use IIS8, and there is the problem, too, if we use unique connectionid. That is sad. Maybe there is something we can do with the help of ServicePointManager, but I didn't figure out it, yet. – Dmitry Oct 23 '12 at 10:14
  • This is actually a browser limitation. If you look at http://www.browserscope.org/?category=network you'll see that most modern browsers only allow 6 concurrent connections per hostname and SignalR will establish one connection per tab. Having a duplicate connection id in SignalR doesn't change this limitation, so I don't know why it worked for you. Maybe websocket requests are not limited, but then there's also no reason to generate duplicate ids. – Alexander Köplinger Oct 23 '12 at 14:44
  • 1
    The thing is, that it worked under IE9 as well, even under IIS7. And that is quite strage... Usually, I try to figure out why somthing doesn't work, but now I'm trying to figure out why it works.. ) – Dmitry Oct 23 '12 at 15:45