I'm trying to create a new application from the ground up. I've used SignalR and WebAPI. I believe I know a lot of the differences, but isn't SignalR faster since it uses websockets? WebAPI makes sense to me for external frameworks to be able to reuse. SignalR makes sense to me for anything I'm not necessarily going to use externally. I've done some research and I can't find anywhere it says you shouldn't. I realize this is somewhat opinion-based, but why would you use a mix of the two rather than just SignalR?
I think what I'm mostly asking is if it is wrong to use SignalR to send back to the caller, except in cases where I would send to other clients on that channel? To me SignalR can be used like WebAPI when you are just sending back to the client. Is that wrong to do? It is less code for the client calls(2 lines vs 6 or more, depending on what I'm doing with it). My thinking is I may be trying to manipulate data and send it to the caller now, but maybe I want to send it to all clients later or send a notification to all clients. I'm not a fan of using signalR calls in my webApi controllers. It just feels like the signalR calls should be in the Hub. Thanks for your help.
There is no reason why you shouldn't use them together because they target two different problems. Web-API is a means of making web services easy to target by many different kind of apps/devices whereas SignalR offers bi-directional communications in a way that the Server can call a piece of code on the client without the client having to keep polling the server for results.
E.g. Instead of having a client keep asking the Server for any new messages (like facebook notifications) with SignalR the server knows that there are new notifications for a specific client and it can send them directly without the client having to ask for them.
http://www.asp.net/web-api
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://www.asp.net/signalr
ASP.NET SignalR is a new library for ASP.NET developers that makes
developing real-time web functionality easy. SignalR allows
bi-directional communication between server and client. Servers can
now push content to connected clients instantly as it becomes
available. SignalR supports Web Sockets, and falls back to other
compatible techniques for older browsers. SignalR includes APIs for
connection management (for instance, connect and disconnect events),
grouping connections, and authorization.
A potential problem is that while SignalR is great at targeting JavaScript code on a client, Web-Api enables connectivity with all sorts of platforms and devices. So the same techniques used through SignalR to target Web Browsers, will not necessarily work on a native Android App.
You can use them together depending on your application needs. I recommend you look at difference between HTTP and WebSockets protocols. WebApi uses HTTP(S), SignalR mostly WebSockets and in some cases others transports. They both have benefits and disadvantages. The main benefits of using SignalR are duplex bidirectional communication as mentioned above and low traffic overheads. Browsers send as a rule a few KB data in HTTP headers and cookies for every request.
It’s easier to use RESTfull services (HTTP) from browsers, HTTP clients, tools, languages and so on instead of using WebSockets. Google Chrome supports monitoring WebSockets traffic but very poorly and Microsoft Edge doesn’t.
Many tools like Google Analytics and Microsoft Azure Application Insights can monitor errors in HTTP requests but can’t do this for WebSockets. You need to implement monitoring manually. Actually WebSockets traffic is simple messages from client to server and vise versa, no additional information. SignalR has some wrappers for this - some kind of error message format.
WebSockets also use more server resources because of keeping open TCP connection and it’s harder to scale web applications that use WebSockets. For instance if you have 100K online users it means you have to be able to keep 100K TCP connections. For HTTP – not necessary. For some very simple sceneries you can replace SignalR with some kind of client polling, but be careful that’s approach may bring a lot of problems.
So, If you don’t need bidirectional communication and traffic overhead (as a rule a few KB per request) is not a big deal then use WebApi only.
If you need bidirectional communication you can use SignalR for server to client push notifications and WebApi for client to server requests simply to ease development, scaling, debugging and using API from other sources. But you also can use SignalR only if you are ok with disadvantages of it or traffic overhead is big for you.
Related
I am running an ASP.Net Web Forms application in an Azure Cloud. Now I have a special requirement that I have no idea how to solve: the server has to accept incoming connections over the internet from Android clients and then keep that connection open (or on standby) for a long period of time (days). So after hours or even days, the server has to find it's way to the Android client and send some data to it. I can use whatever technology works for both partners, but since the internet is in between, http/https is prefered as protocol (although WCF with TCP endpoints might also work when the connection is initiated by the client). The only thing I can think of is having the clients constantly poll the server if there is a command/data available, but that solution is ugly and wastes a lot of ressources. The client should react within seconds when the server has something to do for it, so I'd have to use a polling interval of ~10s. I know that http "keep alive" exists and can be utilizied in C# WebClients, but I doubt that it will work with my requirements? Is there any other possibility to achieve this?
Based on Niraj's response, I found Google Firebase Cloud Messaging. After that, I read up on the XMPP protocol and the SignalR technology available for .Net and finally decided to go with SignalR as it's implementation is most simple and does not require involvement of a 3rd party.
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
I recently discovered SignalR, seems that it can fit into high-load projects with hundreds of concurrent connections.
But as far as I can see, it is only supports full communication type of software (real-time).
So here is the question: is it possible to create REST services with SignalR without client code & persistent connections?
Basically I just need that asynchronous high performance server side part from SignalR & HTTP request handler (if exists).
Regards.
Nope that's not SignalR's purpose, use WebApi if you want to make a streaming restful api. Take a look at push content http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx.
I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.
Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.
As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.
Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.
The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).
Right now, our options as I see them are:
Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management
My basic question is this:
What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?
(I am working on the assumption that by "stateful" you mean session-based).
I guess one big question is: Do you want to use SOAP in your messaging stack?
You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!
Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.
You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.
What sort of state do you need to store in your sessions? Maybe there are alternative approaches?
1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless.
2) consider distributed caching, perhaps Windows Server AppFabric Cache.
I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?
Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.
If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.
Remoting
If all development is done in .NET 2005, Remoting is the best way to go.
MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.
The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.