I am working on an Angularjs and Node.js based application. This is an organization based application. In this app, I have to implement chat functionality. So as we all know Socket.io is the best solution for instant messaging app and its reliability. But apart from this, I have few doubts regarding Socket.io. As of my understanding when we use socket programming (Socket.io in my case), for each and every connection it reserves a port. What if the size of an organization is too big? Will it work? At the server side, I am using Express js. Will Socket.io creates extra load on the server?
Should I go with Socket.io or HTTP?
Thanks.
HTTP polling for any sort of interactive timing is enormously inefficient. You will have tens of thousands of clients repeatedly asking your server, "do you have anything new for me?" and the server regularly responding "no, nothing yet".
webSockets (which socket.io uses as the transport) were invented precisely because they are more efficient for two way, interactive communication than HTTP polling.
Modern servers can be configured to handle hundreds of thousands of simultaneous webSocket connections. How many a single server of yours can actually handle in the real life working of your application depends upon dozens of factors, none of which you've disclosed in your question. But, selecting webSocket/socket.io is not a bad architectural choice for two-way chat - that's the kind of application is was invented for because it's generally better than HTTP polling at that sort of thing.
See these references:
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
Can this technology stack scale?
Do HTML WebSockets maintain an open connection for each client? Does this scale?
600k concurrent websocket connections on AWS using Node.js
Node.js w/1M concurrent connections!
HTML5 WebSocket: A Quantum Leap in Scalability for the Web
For beginners, chat using socket.io is really simple to understand and integrate. However, the amount of bandwidth will depend heavily on the amount of data you're going to send from the server, and how much data the client will send. The bandwidth usage will also depend on which Socket.IO transport you're using, and the heartbeat interval of your application.
The performance impact of the application also varies on the type of application you're running and the performance capability of your machine and/or network. However, 5000+ clients will have a considerable impact on performance, regardless of your computer's capabilities unless you are scaling the application across multiple cores.
You can refer to this link for more details. Link
Go with Socket.io. It is incredibly relevant today for highly interactive applications like chat module. With web socket, there is no negotiation protocols and connection remain open as long as users concerned are registering for service with the web server. The payload is significantly less than http/https protocol.
Related
I have a service running as a sidecar next to a variety of applications.
This service needs to be extremely fast and do not make remote calls.
It has to have in-memory database. The contents of this database have to be populated and kept up-to-date (although a lag is acceptable) with a central component.
The service does not accept writes.
Of course this could be done through a mechanism of long pooling, for instance, but this brings the complexity of managing this solution and some intrinsic inefficiencies.
Is there a lightweight, ephemeral in-process and preferably in-memory database that can synchronise asynchronously with central replica preferably through regular HTTP so that no ports needs to be opened?
Maybe Couchbase lite/mobile is what you are after. Atleast mobile is syncing over a web socket, not sure about which protocol lite is running (or if there is actually a difference between the products).
Seems like couchbase lite replaced touchDB which was a mobile version of CouchDB IIRC.
Another variant might be running pouchDB and using CouchDB as the master backend. You don't say which platform the application will run on, which is relevant if you want an in-process solution.
Is there a Platform as a Service (PaaS, e.g. Google App Engine or Windows Azure) that for a reasonable cost can be used to run a server for relaying peer to peer "real time" communication between clients?
This system will in my case be used to relay (small amounts of) network traffic to and from small home automation gadgets with limited resources programmed in embedded C, to Android and iOS apps. In a few years I expect several tens of thousands of simultaneous connections.
The reason I am looking for a PaaS solution and not IaaS is that I would like to minimize the time and expertise needed for virtual computer, OS and server application maintenance.
Because of the resource constraints of the home automation gadget, a solution like PubNub is not possible. I have a few thousand bytes of available program flash for my embedded C code, so the protocol used would have to be pretty basic (e.g. raw TCP or UDP, HTTP or WebSockets).
Using "long polling" with Google App Engine (GAE) would be too expensive, as they bill for the whole duration of the connection even if almost no traffic is transfered. GAE supports Sockets, but only outgoing sockets and not listening sockets on the server. Is it possible to get around this limitation somehow by e.g. sending a UDP packet to GAE first (to punch a hole in the user's firewall, and having GAE then initiating an outgoing socket back to the home automation gadget or Android/iOS app?
Or do you see any other possible solutions using the PaaS aspects of Windows Azure or other PaaS providers?
Any tips or possible solutions are greatly appreciated!
AMQP seems like it would fit your protocol needs and the Apache Qpid/Proton project has some client libraries, their C code might meet your needs. On the service side you could test things out using Azure ServiceBus since it speaks AMQP. If that didn't meet your needs you could host a worker role and run one of the AMQP clients in there.
Another option to consider is ZeroMQ. They have a lot of very simple client APIs and building a relay service that ran in a Worker role would be a trivial amount of code. Java Sample C# Sample Those samples are using an "inproc" transport and I'm guessing you want to switch that to TCP.
I am just brainstorming here. Let's say I have 2 mobile devices, iPhone, Android, WinPhone7, BlackBerry, Palm, whatever. I'd like to communicate my location (latitude/longitude) from my device to another one. What is the best way of doing this?
The assumption that each device has either built-in mapping capabilities or a custom-built native app.
I've thrown around ideas like SMS/MMS or email with links embedded in them. However, they all seem to be cludgy.
Any other ideas?
A web service (or, if you must and don't care about security, Twitter) that each phone could poll for changes to location might work out. The web service would have to accept the coordinates, obviously, plus be able to be polled for updates by each device. Security is obviously a concern, but that might be another way to go provided that each device had a custom app to accomplish this task as well as web access to poll for changes.
I would go for SMS. It is guaranteed to be private, reliable, low-cost and easy on battery.
Web service is also an option, however:
privacy is a concern, as the data will leave mobile operator internal network
reliability - well, you would have to build your own messaging system and that can always fail
end-user cost - in order to access web service, end-user would have to activate a data session and constant polling can be a source of significant traffic.
development cost - you would need to develop that web service
battery life - constant polling over the data connection will have an effect on the battery.
Compare that with SMS:
privacy - SMS never leaves operator network, so it is guaranteed to be as private as your phone calls are.
reliability - SMS center is guaranteed to always be there by your mobile operator to accept your messages
end-user cost - in most networks, SMS cost is negligible
development cost - well, as SMS center is already there, you can use it without any additional effort from your side (excluding your soft that needs to send and receive those SMSs)
battery life - no adverse effect on battery
In any case, both devices still have to have a "mapping app" that you can program to interface with the SMS/web-service data.
This is more out of curiosity and "for future reference" than anything, but how is Comet implemented on the database-side? I know most implementations use long-lived HTTP requests to "wait" until data is available, but how is this done on the server-side? How does the web server know when new data is available? Does it constantly poll the database?
What DB are you using? If it supports triggers, which many RDBMSs do in some shape or form, then you could have the trigger fire an event that actually tells the HTTP request to send out the appropriate response.
Triggers remove the need to poll... polling is generally not the best idea.
PostgreSQL seems to have pretty good support (even PL/Python).
this is very much application dependent. The most likely implementation is some sort of messaging system.
Most likely, your server side code will consist of quite a few parts:
a few app servers that hansle incoming requests,
a (separate) comet server that deals with all the open connections to clients,
the database, and
some sort of messaging infrastructure
the last one, the messaging infrastructure is really the key. This provides a way for the app servers to talk to the comet server. So when a request comes in the app server will put a message into the message queue telling the comet server to notify the correct client(s)
How messaging is implemented is, again, very much application dependent. A very simple implementation would just use a database table called messages and poll that.
But depending on the stack you plan on using there should be more sphisticated tools available.
In Rails I'm using Juggernaut which simply listens on some network port. Whenever there is data to send the Rails Application server opens a connection to this juggernaut push server and tells it what to send to the clients.
Our tests showed that the polling duplex binding simply does not scale and can not be used on a service within a web-farm or even a web garden. We have looked at TCP/IP sockets for a client push method, but the firewall issue is does allow us to use sockets.
I was wondering what is the alternative "free" solution to this problem? allowing us to scale and allowing us to push data to client...
I have also tried the solution in this article http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html but at the end, there was too much polling on a database, and performance was affected.
Our Silverlight application need a pub/sub design, but it needs to be reliable and scalable... any ideas?
I heard about lightstreamer, which scales very well , but I´m not shure about license fees
Also have a look at this intresting conversation at silverlight.net
Check out WebSync, it's a full comet server built for .NET. It handles server farms, and over 30,000 simultaneous users per server on commodity hardware (3 gig ram, cheap AMD 3 core processor). It's not free, but it's a great solution. There's even an example running silverlight here.