Investigating solutions for notifying WPF clients from server

The point of technologies like SignalR are to meet the demand for realtime communication between servers and web clients. They take advantage of WebSockets and fallback to older/hackier communication mechanisms for older web browsers.

If your environment is going to be a LAN and your client a .NET app then you could use a TCPServer and multiple TCPClients. When your web server has an update/message to send tell your TCPServer (maybe by putting a message on a message bus which it's listening to) which can inform the connected client(s). Realtime web technologies are a great way of doing this but it really depends what your current requirements are and what your plans for the future are:

• Do you want to try out SignalR - If yes, then it'll work and you'll probably have a lot of fun. It might also be useful for future projects and be a good string in your bow. If no, a TCPClient and TCPServer approach might be super-simple and faster to do.
• Do you have a requirement for other types of web client to be able to receive the notifications in future? - yes, SignalR or another more mature self hosted realtime web technology might be a better solution. No - TCPServer/Client
• Do you plan to distribute the data outside of your LAN? Yes - a self hosted option or event a hosted solution with .NET libraries may be the way to go as they remove the maintenance overhead (Disclaimer: I work for Pusher who offer a service like this). No - self hosted or TCPServer/Client.
• How much does speed matter? If it really matters then a TCP connection with absolutely no overhead will be the fastest option. The seco

This question is interesting.

We are currently developing an application that interacts with multiple Web Services. One of the requirements is that each client must be kept aware of the actions done by the other clients.

In order to achieve this, we're thinking of creating a Web Service whose purpose is only to build a list of clients to notify, and to handle the logic behind who is notified, when, and the content of the notification. The clients would register with that Service when they are launched. The notifications themselves would be done using callbacks as you mentioned.

The reason behind using a completely separate Web Service was due to the fact that all our existing ones required connections to be established and dropped on every call. With the notification Web Service, connections have to be maintained as long as the clients run.

I'm sorry I could not be of much more help, as we're in the process of developing such a system ourselves. I'm also interested in obtaining feedback on this subject.