1

I am developing an application which must run on up to thousands of client systems that I control (Linux) which are connected behind common NAT devices to public Internet. Each of these client devices must receive infrequent messages from a cloud service (1 or 2 per day) and on average, must receive these messages in less than a 500ms.

I have full control of both server and client systems to install any operating system, programming languages or applications. However I will not have control of the router and network in between. Otherwise, I could just call a web service running on the "client" devices in order to send the messages.

I have considered running Node.js on the cloud service, with javascript sockets on the client kept open 24x7. From what I am told Node can handle tens of thousands of open connections, making it an ideal server for this.

NAT devices will time out open connections, so dummy keep alive data could be sent. And if the connection is dropped, the client just renews the socket.

Other options include Erlang or even a simple c socket with long polling.

However I am having a difficult time researching this problem for other approaches.

What would be the best approach? Given no restrictions on language or programming.

Improve this question
6
  • 1
    is it an option to have the clients communicate with each other?
    – ratchet freak
    Commented Jul 8, 2013 at 0:31
  • @ratchet freak No, the clients will not be able to communicate with each other. Sorry, to make it clearer they will all be on separate networks, but connected to the public Internet.
    – user1724280
    Commented Jul 8, 2013 at 0:55
  • 3
    As soon as you have the messages being passed over the internet you're at the mercy of it. It doesn't matter what language or clever code you've written, a congested network will cause you problems and it's completely out of your control. Your best bet is to have a very close look at the hardware side of things first. Check the link speed to and from servers and check what's in the contract in terms of guaranteed uptime and availability. Once you've got that sorted start looking at the code.
    – Rocklan
    Commented Jul 8, 2013 at 2:41
  • @LachlanB -- Yes I do understand that the network itself will be a limiting factor. However I just want to find the right software architecture to push through the message as fast as possible when possible.
    – user1724280
    Commented Jul 8, 2013 at 3:04
  • 1
    Consider using UDP rather than TCP. You will still need to traverse the NAT so your clients will need to periodically ping the server and you will need some sort of acknowledgement mechanism but overall it should be simpler than TCP.
    – Guy Sirton
    Commented Jul 8, 2013 at 3:18

1 Answer 1

Reset to default
1

One way of handling this is to use PubNub. It is a paid service, but well worth it since it basically handles the entire messaging portion of what you describe, and wouldn't have any scale issues.

Its very easy to implement. The clients would connect to the service using long polling (if you roll your own) or one of their client libraries. Messages are passed as JSON.

I have used PubNub for a commercial software project, and it works very well.

Improve this answer
2
  • 1
    This is actually a great option. This would allow us to have a viable solution immediately and work through the best options to develop our own for the long term.
    – user1724280
    Commented Jul 8, 2013 at 18:13
  • If's a great option please at least mark up the answer or even accept it :)
    – adrianmcmenamin
    Commented Aug 6, 2013 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.