On Sunday, March 22, 2015 at 11:33:51 AM UTC-4, Jothi Sankar wrote: > > Hi Everyone, > > I am a beginner in Node.js. I have been working on some back-end server > API that will listen for location information from our client devices and > the API will drop a pin on google map that will be rendered in server ( > without reloading the page ). We have been discussing about the server > capabilities.In our case we are about to handle millions of server > requested so we need a concurrent server like Node.js. We have been > searching for the optimized way of implementing this in Node.js > > Need clarification on some basic area. Hope the community will clarifies > our doubts. > > Should our server as HTTP server? > Coz on client devices does nothing with the responses from the server. > It can be avoidable. > What will be best suitable server for us like TCP? > Shoule we use web-sockets for this? >
What protocol you use depends on the constraints -- if you are on unrestricted networks, and using a native app, TCP can be a great default communication protocol, and probably your lowest overhead. Web browsers, however, won't speak plain TCP. You can use HTTP-based protocols -- long polling, and where there's no proxy to interfere, websockets. Websockets, once established, have less overhead than most HTTP-based communication since there's not headers going back and forth on each transaction, and the connection stays established. Long polling HTTP is probably the most widely available, but also the most inefficient of the three protocols. (Could do worse... could always do short polling) Your bottlenecks will be on the number of sockets a single server can maintain -- file descriptor limits in your OS, buffer memory allocation per socket, lots of tuning when you get over 10,000 simultaneous connections per server. It's completely doable, but it's going to take some effort to scale that. Tools like engine.io and socket.io have fallbacks, so they try different protocols and try to use the most efficient one that works given a network. I personally tend to go somewhat low level, to get the control needed to scale easily and to have less to debug, but your mileage may vary. You will want to look at which direction the information flows (in to server, out of server, both), how often (is it a continuous stream, or is it periodic updates?). If the information flow is bidirectional, or if it's constant, streaming, TCP or websocket-like things are best. If it's one-way, from client to server, and intermittent, then it may make the most sense just to use plain HTTP and PUT or POST some data periodically. > > Share some tutorials that will really help us to understand the node > server better. We are happy to learn but we need some one to guide us in > right direction. So came here. > I don't know of tutorials offhand, but it sounds like you've got something interesting going on. Building a couple prototypes to test APIs and protocols is probably your best bet -- something super light, just to understand how you're actually sending data. Aria -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/3e0635cc-a1a2-4a59-854c-535816d4b164%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
