Jimb Esser is totally correct. Forget about that number of packets... NO
WAY is that going to happen in the real world. You are only mentioning the
littlest number of game packets from clients, in reality you will have much
more (even though maybe less players per radius). You aren't going to
successfully be able to pull off the server sending that many packets. I
would suggest you also find a good medium for packet size. You will want
the packets considerably large (~256-512 bytes as a guess). You will most
likely end up storing more than one user... and more than one user event in
a single packet from the server (and possibly from the client as well). You
will also want to only encrypt important information, and possibly even use
UDP for non-important information.
Your best bet would be to make a benchmark environment and test this out. I
have a decent amount of low-level TCP/UDP programming experience in games
(though I have never used Node for this), and the methods used are best
designed for the game type in question (meaning you wont ever have a
performance based single game network code base). There is no single "best"
answer, especially not without bench-marking.
Also, you would be wise to design the server architecture such that you can
scale easily (add more servers).
Good luck!
On Monday, August 11, 2014 8:42:51 PM UTC-7, Majid Arif Siddiqui wrote:
>
> When you look for resources on *Node* a lot of it are mostly centric on
> the *web* (*http*). But *Node* is more than the *web*, so I wish there
> are also more focus on the other aspect of *Node's* networking
> capabilities other than *http*.
>
> When working on a *Game Server *you need high concurrency and also some
> calculations. Some of the important points on game server development are:
>
>
> - Receive
> - Frame
> - Decrypt (because it's always encrypted from the client)
> - Deserialise (we still use binary when passing data NOT JSON)
> - Handle
> - Encrypt
> - Serialise
> - Send
>
> The list above it what happens for every incoming request from the client,
> and that is just the tip. Imagine 200 concurrent players on the same area,
> when 1 player moves, this update gets sent to all other 199 players. Server
> receives one packet, sends out 199 packets. If all players walk 5 steps, 5
> steps = 5 packets, 5 packets * 200 players = *1,000* incoming packets.
> 1,000 * 200 = *200,000* outgoing packets. This can all happen in 1
> second, and should be smooth in each players perspective.
>
> Questions:
>
>
> - Is it true that one should keep callbacks/functions short to avoid
> blocking the event loop too long? How short should it be?
> - When decrypting/deserialising/encrypting buffers (cpu calculations
> heavy, custom routines) should I use a C++ add-on? Should I use pure
> javascript and pass each task to a child process?
> - serialising is like converting a JSON structure into a buffer,
> should I use the node buffer, an array or a typed array?
>
> Currently I am thinking of doing something like this to handle JSON to
> buffer.
>
> obj =
>
> id: 1,
>
> name: "obj"
>
>
>> arr = []
>
> for k in obj
>
> v = k[obj]
>
> if v instanceof String
>
> for i < v.length; i++
>
> arr.push(v[i])
>
> else
>
> arr.push(v)
>
> return new Buffer(arr)
>
>
> This way I wont have to define the buffer length first. But is this
> proper? Of course I left out the part about doing stuff like:
>
> serialize.uint16le = function(val) {
>> var binary = [];
>> binary[0] = val & 0xff;
>> binary[1] = (val >> 8) & 0xff;
>> return binary;
>> };
>
> deserialize.uint16le = function(pointer, buffer) {
>> var binary = buffer[pointer.offset++];
>> binary |= buffer[pointer.offset++] << 8;
>> binary >>>= 0;
>> return binary;
>> };
>
>
> But how will this fair performance-wise against just using the built-in
> buffer methods?
>
> In *MMOG*, performance is one of the make or break for games. Slow or
> laggy games will make the players loose interest. I'm talking about heavy
> lag because the server is getting slower, not because of network problems.
>
> Cheers,
> Maj
>
> PS. I'm just a *MMOG* server hobbyist.
>
--
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/f085dcf9-6672-4dd0-9170-11433af3dd5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
