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
Related
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.
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 developing a multiplayer Javascript/canvas game that uses WebSockets to communicate player positions and states etc. I'm comfortable coding this in Javascript, but it's the server-side websockets stuff that I'm having trouble with.
I have no idea how I should implement WebSocket support past the client side Javascript. Do I add a module to Apache? Do I do it in PHP? Do I use something like node.js? As far as I know node.js has received a lot of praise about this sort of stuff, but I still have no idea what it really is other than a web server.
I would recommend using nodejs, along with socket.io, which is a cross-browser compatible web sockets style library. It makes it really simple to write code which communicates with the server (==nodejs) in real time. It uses web sockets in browsers which support them, or other technologies in browsers which don't.
Just a note regarding PHP since you mentioned it... It is not very suitable for this in my opinion, since, as you may know, a PHP script only lives the duration of the request. This behavior makes it difficult to implement real time communication, unless you roll your own server with PHP, skipping Apache or such entirely.
Another alternative could be using Python, and perhaps something like Twisted, although you may need to implement websockets or such yourself.
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 have a game server written in python and twisted, and an old game client also in python. I have written a new game client in Javascript, which will connect with websockets. Now I face a design decision, should I,
Re-write the game server in node.js, using miksago's websocket server and pure javascript
create a forwarder with node.js and miksago's websocket server, which will create a connection to the old python server with traditional sockets for each websocket connection it recieves.
Use gleicon's websocket server for twisted+python (this actually looks like a pretty good idea and I'm thinking I like it, but I'll post this question anyways.)
EDIT: links and clarity
There's a lot of info missing here.
Are you currently (un)happy with Python or Twisted or you game server implementation?
How large an effort do you estimate reimplementing it in JavaScript will be?
Are you already familiar with Node.js?
What advantages do you see in a JavaScript server implementation?
Are those advantages worth the effort to you?
Option 1 definitely looks scary, but it might not be for you. It's important you don't land in a situation where you derail your own project, because you've embarked on this huge effort that you may at some point lose the motivation for to finish.
Option 2 and 3 look easier to accomplish. I figure the main differences are having to learn Node.js and an extra daemon process to manage for option 2.
You can always choose to do 2 or 3, and move up to 1 if you're unsatisfied.
I assume you are doing this because you also want a browser based game client to be able to connect although it's not clear from your question.
You might look at wsproxy which is included with noVNC (HTML5 VNC client). It is a generic WebSockets to TCP socket proxy. wsproxy is used with noVNC to connect to VNC servers that don't have WebSockets support. There are three separate implementations of wsproxy in C, python and node.js.
Disclaimer: I made noVNC (and wsproxy).
If you're crazy and really know JavaScript a re-write should be a very good exercise in Node.js.
Although it depends on how much code you got, having both the client and the server written in JavaScript reduces context switching and gives you re-usability of the code if you're doing clients with lots of interpolation.
I'd say go for the rewrite if you want to learn Node.js and you already know how to do asynchronous programming.
Also, I did 2 game server with Node.js, so if you got further questions down the road I've got plenty of experience:
https://github.com/BonsaiDen/NodeGame-Orbit
https://github.com/BonsaiDen/NodeGame-Shooter
You may also want to check out BiSON to save on bandwidth with the WebSockets, I've written that specifically with HTML5 Games in mind:
https://github.com/BonsaiDen/BiSON.js
Yeah, node.js is really suitable for game server development.
The node.js network IO ability is much better than python.
But rewriting is a big price to pay, and you still can not take the advantage of scalability if there is only one node.js process.
There is a already a game server framework that support multiple process and more scalable, check this out:
https://github.com/NetEase/pomelo
And also, there is a full open source demo:
https://github.com/NetEase/lordofpomelo