We Keep Coding

SignalR and WebAPI, why use a combination of the two?

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.

.Net WebSockets in windows Services

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

Two-way Communication Using WCF

I'm designing a client-server architecture which is implemented using Windows Communication Foundation. In one of the use cases, the server needs to request the status of the client(s), which means it needs to call the SendStatus() method on the client and ask for its status. I was just wondering if this use case can be implemented using WCF, without creating a standalone service on the client side. I'm trying to avoid sockets because the client is a background service and is essentially always connected to the server. I understand that WCF eventually uses sockets for communication, but I'm specifically trying to use WCF since this is more like a proof of concept.
A workaround I thought of was that the client could call the SendClientStatus() method on the server and send its status every 5 seconds or so. But then again this doesn't seem like a good approach. Any help would be appreciated.

In the world of WCF, you have more or less two options.
A) A Duplex service with Dual Http Binding
B) A no-return-value polling scheme - this is essentially what you described. The naive implementation, as you correctly note, is not that great, but there are optimizations. Since you do not need anything returned from SendClientStatus (correct?) , you can optimize the communication by only sending an update when there is one - e.g. as long as the status of the client remains the same, nothing is sent to the server. Depending on the frequency with which client status changes, this can greatly reduce the traffic. Duplex services present some extra configuration you want to avoid unless you really need them.

Interfacing with a localhost Windows service

I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!

I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service

You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking

Communication between server and client for WinForms

I have 50+ kiosk style computers that I want to be able to get a status update, from a single computer, on demand as opposed to an interval. These computers are on a LAN in respect to the computer requesting the status.
I researched WCF however it looks like I'll need IIS installed and I would rather not install IIS on 50+ Windows XP boxes -- so I think that eliminates using a webservice unless it's possible to have a WinForm host a webservice?
I also researched using System.Net.Sockets and even got a barely functional prototype going however I feel I'm not skilled enough to make it a solid and reliable system. Given this path, I would need to learn more about socket programming and threading.
These boxes are running .NET 3.5 SP1, so I have complete flexibility in the .NET version however I'd like to stick to C#.
What is the best way to implement this? Should I just bite the bullet and learn Sockets more or does .NET have a better way of handling this?
edit:
I was going to go with a two way communication until I realized that all I needed was a one way communication.
edit 2:
I was avoiding the traditional server/client and going with an inverse because I wanted to avoid consuming too much bandwidth and wasn't sure what kind of overhead I was talking about. I was also hoping to have more control of the individual kiosks. After looking at it, I think I can still have that with WCF and connect by IP (which I wasn't aware I could connect by IP, I was thinking I would have to add 50 webservices or something).

WCF does not have to be hosted within IIS, it can be hosted within your Winform, as a console application or as windows service.
You can have each computer host its service within the winform, and write a program in your own computer to call each computer's service to get the status information.
Another way of doing it is to host one service in your own computer, and make the 50+ computers to call the service once their status were updated, you can use a database for the service to persist the status data of each node within the network. This option is easier to maintain and scalable.
P.S.
WCF aims to replace .net remoting, the alternatives can be net.tcp binding or net.pipe

Unless you have plans to scale this to several thousand clients I don't think WCF performance will even be a fringe issue. You can easily host WCF services from windows services or Winforms applications, and you'll find getting something working with WCF will be fairly simple once you get the key concepts.
I've deployed something similar with around 100-150 clients with great success.
There's plenty of resources out on the web to get you started - here's one to get you going:
http://msdn.microsoft.com/en-us/library/aa480190.aspx

Whether you use a web service or WCF on your central server, you only need to install and configure IIS on the server (and not on the 50+ clients).
What you're trying to do is a little unclear from the question, but if the clients need to call the server (to get a server status, for example), then they just call a method on the webservice running on the server.
If instead you need to have the server call the clients from time to time, then you'll need to have each client call a sign-in method on the server webservice each time the client starts up. The sign-in method would take a delegate method from the client as a parameter. The server would then call this delegate when it needed information from the client.
Setting up each client with its own web service would represent an inversion of the traditional (one server, multiple clients) client/server architecture, and as you've already noted this would be impractical.

Do not use remoting.
If you want robustness and scalability you end up ruling out everything but what are essentially stateless remote procedure calls. Since this is exactly the capability of web services, and web services are simpler and easier to build, remoting is an essentially pointless technology.
Callbacks with remote delegates are on the performance/reliability forbidden list, so if you were thinking of using remoting for that, think again.
Use web services.
I know you don't want to be polling, but I don't think you need to. Since you say all your units are on a single network segment then I suggest UDP for broadcast change notifications, essentially setting a dirty flag, and allowing the application to (re-)fetch on demand. It's still not reliable but it's easy and very fast because it's broadcast.
As others have said you don't need IIS, you can self-host. See ServiceHost class for details on how to do this.

I'd suggest using .NET Remoting. It's quite easy to implement and doesn't require anything else.

For me its is better to learn networking.. or the manual way of socket communication.. web services are mush slower because it contains metadata..
your clients and the servers can transform to multithreaded application. just imitate the request and response architecture. it is much easy to implement a network application like this..

If you just need a status update, you can use much simpler solution, such as simple tcp server/client messaging or like orrsella said, remoting. WCF is kinda overkill here.
One note though, if all your 50+ kiosk is connected via internet, then you might need use VPN or have an open port on each kiosk(which is a security risk) so that your server can retrieve status update from each kiosk.
We had a similiar situation, but the status is send to our server periodically, so we only have 1 port to protect/secure. The frequency of the update is configurable as to accomodate slower clients.

As someone who implemented something like this with over 500+ clients and growing:
Message Queing is the way to go.
We have gone from an internal developed TCP server and client to WCF polling and ended up with Message queing. It's the only guaranteed way to get data to and from clients and servers over the internet. As a bonus, many of these solutions have an extensive framework makeing it trivial to implement publish-subscribe, Send-one-way, point-to-point sending, Request-reply. Some of these are possible with WCF but it will involve crying, shouting, whimpering and long nights not to mention gallons of coffee.
A couple of important remarks:
Letting a process poll the clients instead of the other way around = Bad idea.. it is not scalable at all and you will soon be running in to trouble when the process is take too long to complete.. Not to mention having to handle all the ip addresses ( do you have access to all clients on the required ports ? What happpens when the ip changes etc..)
what we have done: The clients sends status updates to a central message queue on a regular interval ( you can easily implement live updates in the UI), it also listens on it's own queue for a GetStatusRequest message. if it receives this, it answers ( has a timeout).. this way, we can see overal status of all clients at all times and get a specific status of a specific client when needed.
Concerning bandwidth: kiosk usually show images/video etc.. 1Kb or less status messages will not be the big overhead.
I CANNOT stress enough that the current design you present will have a very intensive development cycle AND will not scale or extend well ( trust me, we have learned this lesson). Next to this, building a good client/server protocol for this type of stuff is a hard job that will be totally useless afterwards if you make a design error ( migrating a protocol is not easy)
We have built our solution ontop of ActiveMQ ( using NMS library c#) and are currently extending Simple Service Bus for our internal workings.
We only use WCF for the communication between our winforms app and the centralized service(s)