I am developing a SPA - some of the features require real time bidirectional communication and some do not.
Are there any reasons for mixing XHR and Websockets here?
I suspect since I need to use WebSockets anyway, just using WebSockets for everything makes the most sense, but I'm wondering if there are any considerations I haven't taken into account.
It depends on what the outcome of the XHR request is compared to the websocket connection? Websockets are generally faster by not creating a HTTP header and allow a much larger amount of data to be transferred.
From experience I would work incredibly hard on making all requests / transactions in an application the same - applying DRY principles can make your and everyone else who has to work on the project lives a lot easier.
This really depends on what you are doing in your application. You've hit the nail in the head with this statement:
some of the features require real time bidirectional communication and some do not.
If you need a real time full duplex communication channel then resorting to polling, long-polling, streaming, etc hacks over HTTP just to keep the same king of API everywhere might be a pain.
The same goes for websockets. If you are using websockets in one place switching everything to websockets to have the same API everywhere might turn out to be a pain.
Websocket technology is still maturing, it does not yet enjoy a full set tools or frameworks as Ajax (HTTP) does. A lot of server-side and client-side frameworks deal easily with RESTful APIs accessed over Ajax. Not quite so for websockets yet. For this reason for a large set of use cases it makes sense to stick with Ajax and use websockets only where necessary.
There is also the difference in style. In a RESTful API you are navigating resource URLs, in websocket you only have one endpoint that receives commands. If you can fit all interactions in one style then use one style, just make sure you are not loosing something from the tools/frameworks still centered around Ajax/HTTP.
Related
I am new to web development and I just want to know some performance comparison.
I am building a tetris battle game on the web. Most of the game logics are inside of a server, which is built in C++. For clients, I am planning to use cocos2d-js, which is basically javascript.
Players' behavior will affect opponents. First, users' inputs need to get to the server correctly, the server applies inputs to the logic, and it will send a new game state back to clients. Client only needs to represent sprites on the screen.
My original plan was to implement it with TCP socket since it may need low latency. However, I just realized that we don't use TCP socket on the web.
Is it feasible to use HTTP connection for this kind of application?
Should I try web socket?
What are the pros and cons?
You can certainly use HTTP for this but for real-time communication the best option is using websockets.
Raw Sockets (aka, TCP sockets) are not part of the W3C standard.
Even though some browsers have implemented them, I'd recommend avoiding using them unless you don't care about locking your application with that specific browser.
In general, using Websockets will be your best option, they offer the same performance as raw sockets and are easier to use from JS.
Unfortunately, using a C++ server might be more complicated for this, since your server must implement the protocol, you can find some implementations on the internet like this one, for example.
Or, if you want to have a simpler integration with client/server you could try out Node.js to implement your server logic and use the Socket.io library to handle communication, which will also handle incompatible browsers gracefully. Note that Socket.io uses a different protocol, so I don't recommend trying to use it with your current C++ server if you want to avoid doing lots of extra work.
To sum things up
Raw (TCP) Sockets
Pros: easier to integrate with your current C++ server
Cons: browser support isn't guaranteed, not a (web) standard, will need more work for synchronization, communication, etc.
Websockets
Pros: performance on par with TCP sockets, easier to implement client-side
Cons: you might have to do more work on your server implementation
My personal recommendation would be avoiding TCP sockets if possible and stick to the standards.
Edit: Apparently, TCP sockets might end up being a W3C standard, the APIs are still a draft (and a pretty recent one), so I still recommend against using them (latest Chrome has an experimental implementation).
I think #Sosdoc has given the correct answer. The only thing i want to add that a libarary like SignalR can help you very much with the implementaton of websockets. You might want to check out the c++ signalr-qt project on github: https://github.com/p3root/signalr-qt
First off, I am not asking for any code or anything like that.
all I need is some advise.
I'm creating a roulette game and everything in my roulette game is based on jQuery.
however, as we all know, jQuery is client side so I was thinking about using AJAX to send some details back to server and from the server to the users browser so I can make this roulette game work in "multiplayer" fashion... But the issue is that I don't think its possible to send the roulette's wheel animation to the server and back to users browser so I am a bit confused about this!
In my research I came across some information (old ones) about using node.js and jquery together! I don't know if this is possible or how easy it would be to use my jquery code in node.js as I have never used node.js before..
so the question that i have is:
based on the information i provided above and my requirements, what are my options?
can I use AJAX to achieve what i am trying to do and if so, a bit
information would be great.
if AJAX is out of question, is it possible to use my jquery code in
node.js to achieve what I am trying to do?
ANY ADVISE WOULD BE APPRECIATED.
P.S. I don't want to use HTML5 as 1st I don't know much about HTML5 and also, some devices, browsers do not support it.
Thanks
The best way is to use websockets to ensure real time communication. One of the best alternatives for implementing that could be using a server under node.js. Have a look to this video from Code School node.js tutorials: https://www.youtube.com/watch?v=mtDK4jf4RS0 where is ilustrated how to implement a real time chat. Your problem is based on the same.
There are three parts to a multiplayer game displayed in a browser:
client-side display,
server-side data management,
client-server communication.
If you're already set on your display technology (jQuery), then you're probably going to use $.ajax() for client-server communication. However, technologies used for server-side data management are completely up to you and they don't necessarily have any connection to the technologies used for display and communication (meaning the traditional communication initiated by client).
Basically, use any kind of server technology stack you like. Node.js might do just fine but there are many other viable alternatives. They just need to support communication with the client.
So, to be absolutely clear, your question doesn't really make sense. You might use jQuery in the client and Node.js on the server, but they will never really "work together". They will manage completely separate parts of your application and connect through protocols not specific to either of them.
As for the animation, the animation itself is solely a client-side problem. If you want to "synchronize the animation" across multiple clients, you can let the clients communicate with the server, but they only ever need to send/receive plain data. Then you adjust the client-side animation based on the received data.
As another poster points out, websockets are a better fit for this than regular client-initiated HTTP requests. Not because of "the animation", but because you want all the clients to receive the information about the start of betting at the same time.
I am also developing a MMO game using javascript only. Firstly, there are two different types of javascript here. Usual client side javascript (the one you already know) and the server side javascript (i.e. Node.js).
You will need to develop both client and server before connecting them with jQuery's Ajax. So you need to study Node.js before designing overall architecture of your game.
I read many Node.js tutorials and watched many youtube tutorial videos but I was still confused, before I really sat down and read a good textbook that explained from basics, one like below. Try to get hold of it from your local library.
Express web application development learn how to develop web applications with the Express framework from scratch by Hage Yaapa
Express is the popular framework that runs on Node.js now. So it's worth getting familiar with Express Framework. Once you understand how express app works (not so difficult), you will see how you can frame your game structure like I did :)
In order for many clients to share same animation, there must a server that synchronizes the game state. Ajax can only link between server-client communication in my understanding. There is no mechanism that connects between clients. The clients ask server what number was the result of roulette roll and show the corresponding animations.
Yes, you can use NodeJS and jQuery together.
NodeJS is server-side, meaning that you set up a server (a lot of people use the Express module, which is easy to use), which serves content to clients asking for it. Your server-side code can be in any language supporting sockets, not just NodeJS. But NodeJS is easy to use if you know JS already.
jQuery is client-side, meaning that it's executed by the user's browser, and may or may not have a server-side component (if it doesn't need it), or it might have one where it sends requests to the server-side code. When it requests a page from the server, it can be static content (like when you request index.html) or dynamic via an AJAX request. Client-side browser code must be HTML/CSS/JS (you can't make Firefox or Chrome interpret C, for example).
I'm in the process of building out an infrastructure to support a gaming platform we intend to scale out to hundreds of thousands of users. Since this is in the entertainment / gaming industry, we are expecting a heavy load from each user session, therefore, performance is of upmost importance.
We are trying to parallelize as much of the architecture as possible, meaning API, databases, and applications run off of different servers that can be horizontally scaled. One of the applications is a web app, and we're having the most trouble with this due to a specific scenario involving the same origin policy on legacy browsers.
This application running in the web browser will need speedy access to the models only available through the centralized API. While this is great for our dedicated mobile clients, browsers unfortunately need fully CORS support to interface directly with our API. This is problematic because some of the HTTP verbs are not supported on all browsers (put / delete). Our only known workarounds are, rewrite the API to create more abstraction (we believe this is not a best practice and will increase development time and potentially performance) and work with only POST using JSONP or create a proxy (which will add an extra two leg to the trip and double the latency performance).
Bottom line is, we have boiled this question down to... are these the only two options, or is there something else we aren't considering, and if so, which of these solutions would be better suited to a gaming platform.
Another option to consider is JSONP. By wrapping a JSON response to enable it to be loaded as a script tag, you can avoid problems with the same origin policy.
I can't speak to performance issues of your specific application without knowing the app in detail. I would think that you would see similar performance on the server with JSONP, since your major difference over other methods would be that you are concantenating an extra string.
SOP should not be the problem. Use JSONP for domain-across requests. Wrapping the answer in in a callback method should not be the problem for your server-side part and sould be transparent for the rest of the application. Doesn't break REST style. On client-side library the use of JSONP should also be transparent for the rest of the application.
So, what's about PUT and DELETE? Simply perform a POST and set the X-HTTP-Method-Override header with the intended method. Your webservice handler on the serverside should recognize the header and imply the request with the method from the header. All transparent to the rest of the application.
While JSONP certainly does have "universal" support - it's still a bit hacky and has a few negative side effects: mainly that you can't capture errors.
The reason JSONP works everywhere is because requests made by the script tag fall within the confines of a "simple request", as defined by the CORS specification.
My point? Instead of using JSONP, you could also modify your API (or at least the most commonly accessed parts of it) to fit within the confines of a simple request. Then you get full ability to handle errors without any of the performance impact of preflight requests.
For the places you must use preflight requests, you can cache the preflight responses.
I have a full write up on this technique at Two Strategies for Crossing Origins with Performance in Mind
I've got a couple projects that were built using hookbox to manage real-time message passing between web clients and servers. Hookbox was great -- it totally abstracted the transport layer, exposing a simple publish/subscribe interface across different channels with an elegant security system.
Unfortunately the hookbox project has rapidly fallen into disarray due to the original maintainer's unwillingness to even put in the effort to hand off ownership. (Grrr!) So it's hard to consider it a viable platform any more.
What's a good platform for providing real-time communication with web apps? Requirements:
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
Provides a publish / subscribe metaphor with arbitrary payloads
Allows clients to see what other clients are connected to a channel, i.e. presence
Fine-grained access control through callbacks to any web application (nice to have)
I've heard that socket.io can do some of this, but I get the sense that it's at a lower layer of the stack. Can it connect to non-javascript libraries? Do auth?
I've had a very good experience with NodeJS and Socket.IO over the last 8 months. The server side component has been very stable for me - I can leave it running with a very high message volume and it's resident memory never really budges above 20MB. So far I've only been able to leave it running for about 4 weeks without terminating the server, but that was only because I needed to update my server side code.
Works seemlessly cross browser, using HTML5 websockets or COMET as available. Transport choice should be invisible to application layer. I don't care about ancient browsers (IE6)
Provides a publish / subscribe metaphor with arbitrary payloads
Socket.IO is also a fantastic piece of software. It under active development, and has a simple pub/sub style abstraction built in using EventEmitter (NodeJS) semantics of 'on' (subscribe) and 'emit' (publish). It is also very transparent on the client side regarding the transport being used. I used it primarily for the straight-up WebSocket support, but it can fall back to Flash based sockets, xhr-polling, and jsonp polling.
Client access from both javascript and server-side systems (i.e. in php / python / ruby) -- this is critical
NodeJS is JavaScript, running on the V8 engine. It has a ton of 3rd party modules that provide nice abstractions as well as interfacing with external components, such as a databases or message queues, among many other things. As far as hitting the system with php/python/ruby, it would work as with hitting any other server. Choose your method of communication (basic TCP/IP, or maybe HTTP POSTs or GETs, or even via filesystem) and NodeJS doesn't really care who is providing the data. Personally, I've implemented a C# client that is working great.
Allows clients to see what other clients are connected to a channel, i.e. presence
It doesn't not have any built in 'presence' logic, though with the built in 'pub/sub' logic already in place in Socket.IO, all you'd have to do is store state on the server so new clients can retrieve existing presence data. I've implemented my own basic pub/sub on the server that retains state, and all together (including the NodeJS server code, and the basic Socket.IO stubs) it was only 50 lines of JavaScript (including whitespace).
Fine-grained access control through callbacks to any web application (nice to have)
Not sure what you mean by 'Fine-grained access control through callbacks to any web application (nice to have)'. The pub/sub event/observer metaphor they have uses callbacks, so you hook specific actions to specific events.
Do auth?
I've had no need, yet, to do any auth for our systems, so I can't speak to it directly. However, if you browse the NodeJS modules you'll notice there are many auth modules available, including LDAP and OAuth, not to mention one module that claims to do "OpenId, Google, OAuth, Twitter, LinkedIn, Yahoo, Readability, Dropbox, Justin.tv, Vimeo, Tumblr, OAuth2, Facebook, GitHub, Instagram, Foursquare, Box.net, LDAP"
Although I haven't tried it yet, I started looking into Pusher for a Node Knockout 2011 entry. In addition to JavaScript, it supports the following non-js clients:
Objective-C
ActionScript
.NET & Silverlight
Ruby
Arduino
If messaging via a 3rd party is a possibility, you can try the service for free using their Sandbox plan (20 connections & upto 100K messages/day) and see if it meets your needs. (I'm a little uncertain about the "presence" requirement, though it may be covered in the docs.)
I recoment using node.js which has a lot of libraries for various things. One library for real time messaging is now.js. I don't have a lot of experience with this but have tried it and I would say it worked well and has everything you said you need.
I understand that the idea is to create basic HTTP Requests using GET or POST.
I'm fluent with working in HTML, CSS and a little Javascript. But I've never
touched Ajax or anything to do with HTTP Requests. I understand that Ajax is for dynamic page content, and can be used to call other servers but that requires creating your own Ajax stubs.
Anyway I want to know the best way to go about making HTTP Request ultimately i want call using the KAYAK API and the functions they provide to search flights, but theres a whole session system involved which confuses me even more.
What would you suggest I start with I'm not really a coder (other than HTTP and CSS), and I don't really want to get into learning a whole new language for the purpose of one project so please keep the suggestion simple, maybe using just Javascript.
Also any suggestions on things to read, when it comes to HTTP Requests... not what they are... more how to impliment them.
I'm afraid there is no silver bullet...
In the end you have to choose a programming language, learn it and understand what HTTP requests are and how to make them. Eventually you also want to do something with that data once you have retrieved it and for that you need to learn a programming language anyway.
Note that talking to a RESTful API is in fact not necessarily related to AJAX (and therefore Javascript). That is the point of offering such an API. You can communicate with a RESTful API with any programming language capable of making HTTP requests. There are a lot of desktop applications and mobile apps which do this as well.
So if you are serious about writing a professional piece of software, my recommendation would be to choose a programming language, pick up a beginner book on that language and start working through it. You might get away with reading forums and newsgroups for a while, but in the end you will probably be better off learning it if you start programming in more structured way from the very beginning.