[Development] MuServer on Node.js

[Sam3000]

His repo is unavailable, but you can explore the code directly from npmjs:

To view the content, you need to sign in or register

Lol, about few hours ago i was looking at his github repos, but now 2 deleted, wtf?

 

[pafa7a]

I'm happy to share with you that now we can start & stop & control servers from the mu-admin server (directly from the browser)
Demo:


Update:
- MuWebAdmin: the main menu now supports sub-menus + automatically detects the active one
- MuWebAdmin: you can now watch server logs real-time (in future, we can integrate the logs with Discord private channels )
Video demo:

 

[I Am NoLimiT]

Great progress @pafa7a looking forward you finished this project. Good luck mate!

 

[pafa7a]

update:
- WebAdmin: 3 box settings added to logs pages. Clear logs, reload logs, delete logs
- WebAdmin: When you visit the logs pages, it will first get the latest 500 logs stored in ElasticSearch (500 logs for 3ms ) for the respective app and then will continue with real-time logs
- WebAdmin: All logs are now starting with date & time

 

[redigaffi]

Interesting project, but as far as I know from my experience with Node, it's having an awful computational power because MU it's not a JavaScript based game or a web game.
I think it's good to replace the DataServer, ConnectServer and JoinServer with a Node app because these ones are being used at some certain specific moments defined, similar to a web API being called, and these don't require high computation. But for the GameServer, there's a total different story, and you probably saw a GameServer source code. Node JS is having many limitations, and the main loop is async, so non-blocking IO is applied here (e.g. a character will receive the position correctly and the other characters around your character aren't cause the performance was bad during the constant position update and other million things, and being async means it doesn't care in what order the things are arriving or are processed without having a processing index order or timestamp on send).
Anyway, would be interesting to see it, so good luck.

I'm sorry to say, but this smells like a little bit of ignorance.

it's having an awful computational power because MU it's not a JavaScript based game or a web game.

1. Awful computation? Please backup your claim with data, Node.js is perfectly capable of receiving millions of concurrent requests if optimize correctly. (There is actually proof to this, just Google a little bit)

2. What has to do that MU is not a JavaScript game? The client can be written in any language, and the backend can be written in a totally different language they dont need to be the same.

web API

3. You really think Node.JS sole purpose is to be used for a web api? huh this statment just scream inexperience.

But for the GameServer, there's a total different story, and you probably saw a GameServer source code

Node.JS should be perfectly capable to handle k's of concurrent users, 10k or more easily, for what it's worth, I dont think any private server reaches those numbers. Yes, if you are speaking about 500k connections thats a different story. And that level, the language itself doesnt changes much (yes but) bigger changes that give you more bang for your buck for example:

Move your data storage closer your server, on the same host, same network, use an optimized sql store etc.

and the main loop is async

What's wrong with the main loop being async? As I told, Node.JS is very performant and more if you optimized, Most of the "busy" work on these type of games is actually not CPU work but waiting to send/retrieve data from a store (SQL, or whatever) (add latecncy if its not on the same host/network), thats where the main "work" is, retrieving and sending data the CPU has to wait, so its actually better to be async because instead of waiting to retrieve/send data you actually do other work.

performance was bad during the constant position update and other million things,

Repeat, why should performance be bad?

and being async means it doesn't care in what order the things are arriving or are processed without having a processing index order or timestamp on send).

Isn't that something you just can handle at the application level? You do it? Whats the big deal here. You can have a fifo queue where you add messages in order of arrival, and you process them in that same order, fifo, just one idea, there are plenty of ways.

This is a very interesting project, continue on it! the language choice is good which makes the project more accessible to other people as Node.JS is way more adopted.

Choosing a language should never be done alone because of peromance, a language is chosen because of many factors, of them performance, accesibility, knowledge, and many more. There is no "right" language, there are only tradeoffs.

 

[rodrigoreisb]

I'm sorry to say, but this smells like a little bit of ignorance.



1. Awful computation? Please backup your claim with data, Node.js is perfectly capable of receiving millions of concurrent requests if optimize correctly. (There is actually proof to this, just Google a little bit)

2. What has to do that MU is not a JavaScript game? The client can be written in any language, and the backend can be written in a totally different language they dont need to be the same.



3. You really think Node.JS sole purpose is to be used for a web api? huh this statment just scream inexperience.



Node.JS should be perfectly capable to handle k's of concurrent users, 10k or more easily, for what it's worth, I dont think any private server reaches those numbers. Yes, if you are speaking about 500k connections thats a different story. And that level, the language itself doesnt changes much (yes but) bigger changes that give you more bang for your buck for example:

Move your data storage closer your server, on the same host, same network, use an optimized sql store etc.



What's wrong with the main loop being async? As I told, Node.JS is very performant and more if you optimized, Most of the "busy" work on these type of games is actually not CPU work but waiting to send/retrieve data from a store (SQL, or whatever) (add latecncy if its not on the same host/network), thats where the main "work" is, retrieving and sending data the CPU has to wait, so its actually better to be async because instead of waiting to retrieve/send data you actually do other work.



Repeat, why should performance be bad?




Isn't that something you just can handle at the application level? You do it? Whats the big deal here. You can have a fifo queue where you add messages in order of arrival, and you process them in that same order, fifo, just one idea, there are plenty of ways.

This is a very interesting project, continue on it! the language choice is good which makes the project more accessible to other people as Node.JS is way more adopted.

Choosing a language should never be done alone because of peromance, a language is chosen because of many factors, of them performance, accesibility, knowledge, and many more. There is no "right" language, there are only tradeoffs.

I totally agree. Most of the time used in this case come from network latency rather than processor time. And for the async loop, a simple control using a stack would do. I've seen MMOs writen in Python, one of the slowest programming languages existing.

 

[redigaffi]

I totally agree. Most of the time used in this case come from network latency rather than processor time. And for the async loop, a simple control using a stack would do. I've seen MMOs writen in Python, one of the slowest programming languages existing.

Yeah, Python is also TOTALLY capable. Let's not forget, Python or Node.JS is not "slow", they can be very performant. They are just slow compared to C or Assembly, but still for us humans it stil mind boggling fast.

 

[wolfulus]

Yeah, Python is also TOTALLY capable. Let's not forget, Python or Node.JS is not "slow", they can be very performant. They are just slow compared to C or Assembly, but still for us humans it stil mind boggling fast.

Don't get me wrong, but I don't get the point of comparing that to humans - anything in a computer is magnitudes faster than what a human can do, I think it's not the point here.

Python or JS will only hurt depending on how you are doing things.

Python for example, even though it has support for multithreading, you'll still face GIL bottlenecks if what you are executing in a thread is pure python code. As for node, having things be "async" doesn't mean they will perform any better because what makes async faster in this case is the I/O handling (read: getting code to run outside of V8 scope and getting back once it's done) which allows V8 to schedule other tasks in the meantime. To be performant in both cases, you'd need to only process small tasks inside V8/Python and the heavy processing would be done externally, for example having a worker process that is dedicated to the heavy processing (AI or the stupid original algorithm to check for viewport changes) would already boost performance a lot. Would I personally go that way? Probably not, but it's one design choice you have.

Anyways, just like any other system or language, performance depends mostly on how you design and understand the underlying execution model of the tool you're using. Any language you choose, with proper system design would perform well enough to make it useable, for me the choice falls into just a matter of how maintainable and complex the code can become and how resource/operation heavy it will be - but if you can afford that paying more here, no problem.

IMHO I'd still choose other languages to develop the actual game server (or anything that has simulations or that depends on the server tick rate to work), but it's definitely doable in any language.

> Note regarding Python: I mean the original implementation with GIL as I'm unsure about the new versions where they removed GIL - I haven't read much about it yet to know what exactly changes here.

 

[pafa7a]

Let's stop that discussion here. It's becoming totally out of scope of this thread. Whether or not JS can handle everything or it will be a total fail - it depends mainly on the quality of the code & architecture. Let's see what's gonna happen. AFAIK noone tried that, so you can't say if it's gonna work or not. Even if it turns out that it doesn't work well from the first time, it doesn't mean that the language is the one to blame.
The project is not dead, it's still in "active" development stage. I also decided to make a "terminal version" of the client - not that it have a great use-case, just easier to work with it compared with the original sources (at least for me).

 

[karmagaming]

Don't be jealous guys, this is trying something different, doesn't matter if it's perfect or not, this is one of the thinks that we usually do as developers....try news stuff on the language that we love most.

So keep going!! This is amazing and thanks for share

 

[pafa7a]

just a progress update: Login, character preview, character create and character delete are now done. Now I'm working on character entering the world part

 

[pafa7a]

update: I’ve decided to drop the JSDocs thing and convert everything to Typescript, as it seems like everyone expects it as a default. I’m not a huge fan of it, but I am not the important thing here and if that will make others to join the project more easily - I’m happy
Successfully migrated the JoinServer already. These days will port the rest

 

[Opoink]

bookmark, for now, I hope this project will continue as this will give more flexibility to the server. I also forked the repo so that if there there something I can help with.

 

[zbzalex]

Hi, there. Today i am written some lib for work with bytes like c/java on js

To view the content, you need to sign in or register

It for replace mu-packet-manager
See the doc here:

To view the content, you need to sign in or register

If you found bugs, please submit issue.