1

I have in mind a scenario where a Windows 8 app will act as a server, receiving messages from diverse clients (other Windows 8 apps or Excel Web Apps). Those messages need to arrive at a low latency (<1s in most cases). I am considering many different solutions. I will definitely need some kind of server backbone to do the match making (route the messages to the appropriate device). And I try to decide between

  1. Azure Mobile Services. The source will send messages to Azure and Azure will send them as a push notification to the appropriate "server" device. The problem is that latency here is not very good.

  2. Azure Mobile Services (or something simpler like a simple Web API site) only for matchmaking: actual sending of messages would be established with each client having a web socket connection to the server app. Here we have very low latency, but I fear connectivity problems. The fact that the server won't store any messages is better from a data protection perspective, but makes disaster-recovery and handling moments where the server app will be on the background slightly more difficult.

  3. Azure Service Bus. It's supposed to be made for that (the server subscribes to the feed of client messages), but I think a new queue will need to be created for each server (and then clients will have to learn of the name of that queue, so some matchmaking like in option 2 will be necessary)

What would you recommend?

Thanks in advance!

tec-goblin
  • 196
  • 1
  • 11

2 Answers2

2

I have been developing something similar before, I would suggest that you build this solution using Windows Azure Mobile solutions especially it supports the Node JS NPM right now.

http://weblogs.asp.net/scottgu/archive/2013/06/14/windows-azure-major-updates-for-mobile-backend-development.aspx

For the Client I also suggest that you build it using SignalR which is designed for cases such yours where real time applications require a lot of transactions from the server side.

http://www.asp.net/signalr

you can also find more details about how you can integrate both of them in the following link: http://hhaggan.wordpress.com/2013/07/12/signalr-node-js/

I hope these help you, let me know if you need anything else.

hhaggan
  • 619
  • 4
  • 11
  • Thanks for the answer. What mostly interests me is what do you use Azure Mobile for. If nodejs is working as the server and SignalR for the client, Azure Mobile is limited to authentication, storage and hosting? – tec-goblin Jul 18 '13 at 10:18
  • I'm also interested in knowing what pushed you use Node.js over WebApi server-side. – tec-goblin Jul 18 '13 at 10:22
  • Hello, well the WIndows Azure Mobile services now supports the NPM to be added In it, so in addition to the normal authentication, storage and hosting it can do more. Check this blog post it has an example that has been done. http://weblogs.asp.net/scottgu/archive/2013/06/14/windows-azure-major-updates-for-mobile-backend-development.aspx – hhaggan Jul 22 '13 at 00:17
  • for the question why did I choose Node Js is I was eager to learn about it more. however I knew that its performance is way better when handling a lot on incoming traffic. check this page it might help you. http://stackoverflow.com/questions/6484175/advantages-of-node-js-in-comparison-with-other-web-technologies – hhaggan Jul 22 '13 at 00:21
  • Hosting NPM is an interesting argument (performance arguments don't convince me because I've never seen a comparison of Node.js to asynchronous Web Api). But the link says it hosts "NPM modules". What modules would be of interest to me? (I'm seriously considering proxying Mobile Services through Web Api in order to have a unified API for both table storage and Azure SQL strorage) – tec-goblin Jul 23 '13 at 06:35
  • some people have made some comparison between both the Node Js and the Web API and here are some results that might be interesting for you: http://css.dzone.com/articles/nodejs-vs-aspnet-web-api – hhaggan Jul 23 '13 at 17:56
  • and you can find here another comparison on stackoverflow http://stackoverflow.com/questions/9290160/node-js-vs-net-performance – hhaggan Jul 23 '13 at 17:56
  • 1
    for the modules you can add to your solutions check the following link it is the Azure SDK for Node Js https://github.com/WindowsAzure/azure-sdk-for-node – hhaggan Jul 23 '13 at 17:57
  • For my project I would easily accept a 50% load hit (I don't expect big load) for the added comfort and versatility (Web Api for example handles better CPU intensive tasks), but that's a personal preference. The list of libraries is interesting though. Thanks – tec-goblin Jul 24 '13 at 21:29
0

After some thought, reading your replies (and some others on msdn forums) and analysing my scenario, the query patterns and the technologies I'm more comfortable with, I decided on the following:

A unified Web Api model over SQL Azure (it might even return an OData IQueryable in one case) will handle both message sending and matchmaking.

Message forwarding to the windows 8 hub app will be done through SignalR and Web Sockets. These two links show me how to handle the app going to the background ( http://msdn.microsoft.com/nl-be/windows/apps/jj662740.aspx ) or losing connectivity (http://msdn.microsoft.com/nl-be/windows/apps/jj710180) - still I want to support some minutes of lost connectivity during which the server will accumulate the messages and send all those that have not been received (after a time period the match will be considered over and the database will be cleaned - I am not sure if I'll handle this programmatically or with a Workflow on a Worker Thread. At this point it seems simple enough to handle programmatically).

In case I need push notifications during matchmaking, I can implement them in Web Api (it takes a few more work than in Mobile Services): http://www.codeproject.com/Articles/506733/Windows-8-Notifications-Push-Notifications-via-Win

So it's more like the solution 2. I'll keep you posted if I encounter any complications. I might need a bit more code initially to set this up over Mobile Services, but I think I will be able to expand the solution in a more seamless way once I follow the basic tutorials to set up the basics. I might even try Entity Framework 6, to go all-async and minimize throughput overheads over node.js (but I'm not expecting any serious load anyway).

tec-goblin
  • 196
  • 1
  • 11