I’m currently trying out Photon Cloud for Unity and I’m pretty impressed with it so far. But It got me thinking about multiplayer networking in general, and I thought I would throw this out there. disclaimer: I don’t have network game programming experience. Never have made a MMO, nor do I want to. But I am generally interested in the concepts especially around cloud computing.
Node is great at handling massive # of connections (limited only by the # of filehandles or sockets on the box)
Node excels in non-blocking async mashup situations
Use Node’s HTTP streaming aka keepalive!
No firewall or NAT punchthrough issues because HTTP just works
“But HTTP is slow” … yes not if the TCP socket is already open and streaming in keepalive.
“But TCP too is slow, real games use UDP”. Maybe just dogma with origin that pre-dates http servers that support streaming?
The simplification of using HTTP streams and Node’s programming model should make it easy to deploy in a cloud environment with distributed shared memory.
But obviously have not done any benchmarking It would be a fun open source project for Unity. After I finish my current project I will probably do some prototyping.
Node is not built to handle application that are as latency sensitive as real time simulations.
HTTP is a bloated protocol, and it’s text-based. It will not work. Maybe you can make some facebook game or something, but building a multiplayer game in the sense most people here think about games, will not work ontop of HTTP.
Also, why would “TCP being slow and UDP being fast” be dogma that is somehow related to before HTTP servers supported stream? Mixing up the concepts a bit?
Also TCP is not slow, not slower then UDP (or anything else that runs ontop of IP). The problem with TCP is with how it deals with dropped packets.
Also, rant:
What is with everyone trying shoe-horn Node.js into every frekin’ type of software in the world. Node.js is nothing “revolutionary”. You can get as many connections on a normal old win32 socket using IOCP. Node.js just happned to dumb down async programming enough for the masses to understand it I suppose.
Basically there is NOTHING magical about Node.js, for example your quote:
The above statement is true for ANY other socket implementation that exists today, on ANY platform pretty much. It’s just that most people do not know how to write properly async:ed networking code.
Hmm I honestly wonder why microsoft, ebay, linkedin, yahoo are all using it. Surely they have people on staff who know to do some nice socket programming?
Anyways I appreciate your feedback.
Ha ha so true. I’m going to bookmark that one. I write in C# for all my Unity work. For my part-time (non-gaming related) day job as software engineer, I unfortunately have to sling some Javascript code. Client side only. My boss was asking about Node and what I though about it.
Of course they do, node.js just happened to become popular. JavaScript was basically the first language a lot of people learned, it was inherently async due to the browser, node.js leveraged this to build a very nice server-side environment that a lot of people (old javascript programmers) were very familiar with. Boom, Node.js becomes big.
Node.js is the new ruby on rails, except it uses a language most people can stand (or at least gotten used to by now).
Other companies jumped on the hype (not saying it’s only hype, Node.js is damn good, no doubt about that). Do you really think that two people could write something that all these companies could not? Of course not. There has been many many attempts at things similar to node js inside microsoft and yahoo before. The technologies just never got a good foot hold in the community, were forgotten and then deprecated and dumped.
Node.js has not even done any “new” socket programming, it’s basically a patchwerk of libraries (epoll, v8, etc.) that have gotten exposed to a tidy JS API that looks and works like the browser async model.
It’s really brilliant, I agree. But it’s nothing new, it just happened to be the one tech to become “famous”.
JavaScript on the server existed long before Node.js.
I’m not trying to say Node.js “is bad” or anything. It’s just nothing new. It’s a bunch of libraries put together that exposes an API that i similar to what people were used to (web browser javascript engine-style).
This is true, but also kind of true about anything. The challenge for game servers is generally optimizing for latency. You might very well be able to support 1 million connections, but if the latency is 500ms, it will not be useful for lots of games.
While HTTP is “most likely to work”, there is no silver bullet for firewalls. People that aren’t allowed to create arbitrary TCP connections may very well have issues with HTTP-keepalive style connections. We have had HTTP tunneling as an Electroserver feature for years, and while it generally works pretty well, there are still lots of situations where it just won’t work: Caching firewalls, stateful or inspecting firewalls, etc. The traffic basically isn’t exactly the same as “normal” HTTP traffic, so there can be issues.
HTTP still has additional overhead vs a binary protocol over TCP/UDP. There is always at least a bit of increased latency and the message size is increased, even if you are cleverly packing it as a binary protocol.
This is an oversimplification of the problem. The reason this type of scalability is ‘relatively’ easy for things like websites is because they rely on large parts of their architecture being stateless. This is typically not the case for many multiplayer games, since they generally require users to interact in “real time” where there is also an emphasis on low latency interaction. This basically means it is very difficult to employ typical horizontal web scaling strategies for multiplayer games.
All that said, there is no reason you could not use Node.js, or any other general purpose “web/http” tech for multiplayer games. It is just a matter of choosing the right tool for the job and knowing the various strengths and weaknesses of the platform.
[/quote]
[/quote]
[/quote]
[/quote]
I may have just been unclear and I believe we do in fact agree. I was merely suggesting this was a valid alternative provided you work within the limitations of the tech and choose the right game. Obviously I feel there is a place for specialized game servers since I make them
Lots of people are using it because it’s useful for lots of stuff. The notion that it could be used as a game server for some things seems pretty reasonable to me - i.e. sending/receiving json with a nosql backend. There are other types of games than MMOs, you know. The biggest pain it seems to me is like the Ted guy said, you end up having to run a real webserver in addition to Node.js to do some things, so it’s not as simple as it first appears. But I don’t care too much what the “Unix neckbeards” think about it.
My experience in Unity has made me appreciate single-threaded “event-based” programming, and how it differs from “traditional” i/o, where every new request is a new thread. When I started looking at Node.js, it reminded me of Unity - no guaranteed order of execution, lots of coroutines and waiting for callbacks - like big Update loop.
No one in the right mind would ever use a text based protocol like JSON for anything other then turn based games or those facebook “web games” (or w/e they are called)
Nobody’s pissing in your garden, man. The web games you majestically disregard have their place, and it’s pretty profitable one. If/when I need a socket server, I’ll look at your stuff, since you’ve obviously got The Answer.
It would be a fun open source project for Unity. After I finish my current project I will probably do some prototyping.
]