I have a Web App(.NET 4.0 ASP.NET MVC3) which uses SignalR(1.0.0 alpha 2) with Hubs and Persistent Connections.
With the Hubs I use groups to send push notifications to some clients.
The problem is that when the server is accessed remotely it defaults to long pooling and only the persistent connections work. With hubs the event happens on the server but my callback is not called at the client. It works locally, though it uses SSE.
What I found is that the combination of Grouping the clients and the long pooling transport is causing the problem. I will try to debug SignalR as long as I get VS2012.
To prove this I just got this chat example modified so a hard-coded group was used and long pooling was forced - it does not work, neither on my machine (IISExpress) nor on a server (IIS 7.5). The chat works as long as you use a different transport OR do
context.Clients.All.addMessage(message);
instead of
context.Clients.Group(groupName).addMessage(message);
Here is a sample project.
Is that a bug in SignalR or I'm missing something?
Any ideas why on my deployment server SignalR would fall back to long polling on port 80 but use SSE if my site is configured on a different port?
You need to enable Auto-Rejoining groups.
Stick this in your startup code:
GlobalHost.HubPipeline.EnableAutoRejoiningGroups();
Related
I have a process that runs in California that wants to talk to a process in New York, using Stomp over Websockets.
Also note that my process is not a web app, but I implemented a stomp over websocket client in C++, in order to connect things up to my backend. Maybe this was or wasn't a good idea. So, I want my client to talk to the server and subscribe, where their client pushed messages.
I was implementing my own server when I saw that ApacheMQ supported Stomp over Websockets. So, I started reading the docs.
It says with the last line under 'configuration' at
http://activemq.apache.org/websockets :
One thing worth noting is that web sockets (just as Ajax) implements ? > the same origin policy, so you can access only brokers running on the > same host as the web application running the client.
it says it again in several related searches such as http://sensatic.net/activemq/activemq-54-stomp-over-web-sockets.html
Is this a limitation of the server or the web client?
With that limitation, if I understand right, the server is not going to accept websocket connections from a client, of any kind, that is not on the same machine?
I am not sure I see the point of that...
If that is indeed its meaning, then how do I get around it in order to implement my scenario?
I've not found that bit of documentation you are referring to but from what I know of the STOMP implementation on the broker this seems incorrect. There shouldn't be any limit to the transport connector accepting connect requests from an outside host by default and I don't think the browser treats the websocket requests the same as it does other things like an Ajax case in terms of the same origin policy.
This probably a case that is best checked by actually trying it to see if it works, I've connected just fine from outside the same host using AMQP over websockets on ActiveMQ so I'd guess the STOMP stack should also work fine.
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
I'm new to ServiceStack and want some validation on a pattern we're thinking about using.
We want to use ServiceStack with Xamarin and Message Queues. While I understand how REST works under the covers, I'm not sure how the Message Queues on ServiceStack work and if its appropriate for mobile devices.
Specifically we know that all mobile devices are essentially behind a NAT firewall setup by the Telco. Meaning Clients can talk to servers, but servers cant talk directly to clients, without the client talking first.
While the concept of a ServiceBus is designed specifically to handle this case, i'm not sure if its "mobile network friendly".
I would assume that the client side implementation, would need to work in one of two ways: polling, blocking get.
Polling would have the client side frequently runing a Http GET to ask the server if anything is available on a queue. A Blocking Get would, perform a Http GET but have the server return nothing until data is ready. Or is there another technique that i'm missing?
If it is a poll, is there any way to control the Poll frequencies in service stack. If its a blocking get how is this configured..
What happens when the app goes to the background, do we need to cancel the connections manually. etc.etc.
We tool an old version of the ServiceStack client library and ported them to xamarin. We now see that the latest ServiceStack client side library is Xamarin compatible.
So, basically my question is: Had anyone used Message Queues from a Xamarin Mobile to ServiceStack with RedisMQ or other server side message queue.
I have an API application and a web application (for simplicity on the same server -- I'll do the CORS stuff later).
Windows Server 2012 with IIS 8.5
Websockets installed through "Programs and features"
Firewall turned off
The api is using owin + signalr and has the proper initialization (trimmed it down to find the error):
public void Configuration(IAppBuilder app)
{
GlobalHost.Configuration.TransportConnectTimeout = TimeSpan.FromSeconds(5);
app.MapSignalR();
app.UseWebApi(Startup.CreateConfiguration());
}
private static HttpConfiguration CreateConfiguration()
{
HttpConfiguration configuration = new HttpConfiguration();
configuration.MapHttpAttributeRoutes();
return configuration;
}
Everything seems to work perfectly except connection to the actual websockets. Every time the client tries to establish a connection, there is a timeout and it fails over to SSE (or forever frame/long polling in IE). I increased the timeout to 25 seconds and the same symptoms are occurring.
On the client, I consistently get this error with logging turned on:
SignalR: Connecting to websocket endpoint 'ws://[myurl]'.
SignalR: Websocket opened.
SignalR: **webSockets timed out when trying to connect.**
SignalR: Closing the Websocket.
SignalR: Attempting to connect to SSE endpoint 'http://[myurl]'.
SignalR: EventSource connected.
SignalR: serverSentEvents transport selected. Initiating start request.
SignalR: The start request succeeded. Transitioning to the connected state.
I have tried following the guides provided by the signalR team and I cannot see what I am missing.
Thanks for any help!
UPDATE:
I downloaded a sample and ran it as-is on the server.
Same situation, so this is likely a server configuration setting that I missed along the way. I still have not found what I missed.
You need to enable WebSockets for the website in Server Manager.
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support
Try establishing a SignalR connection from your Windows Server machine itself. This might have something to do with the network. Perhaps there's a proxy or something in between the client and server that doesn't properly support WebSockets.
If you are inside of a network with a "corporate" firewall, it can screw up the websockets handshake.
But, you can prevent this interference if you access your server over SSL. I've seen this first hand be the cause and solution multiple times for websockets problems in corporate environments.
It may be something with your IIS settings. I saw these on http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/supported-platforms
-IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport.
-The hosting application must be running in full trust mode.
Also, it mentioned something about .NET 4.5 being the target framework. Hope this helped.
When I connect to signalR hosted in same virtual directory, I get data via websocket transport. But in case of cross domain, long polling is getting used as a transport.
Here browser compatibility is not an issue as I am trying in Chrome browser.
What I can do to use websocket as a transport in case of cross domain.
I have tried every possible solution available on net, including available at signalR wiki.
https://github.com/SignalR/SignalR/wiki/SignalR-JS-Client-Hubs
Thanks David for answering my question in the comments:
Because only IIS8 supports websockets and neither SSE or ForeverFrame works cross domain so you're stuck with long polling –