Ryzen Emulator [Javascript/ES6/ORM/Post-Shuffle]

Hello frenz! About months ago I felt want creating a new project, solely for educational purposes. That's why I started this project bleh

What should it be?
Oreo (Google s2) is a cross-platform Habbo emulator, written entirely in Kotlin. I prefered use kotlin than java, because is more concise (POJO in a single line, singleton object) and some enterprise are moving to it, like Pinterest and Evernote.

My first aim is make a really stable and scalable emulator with total code coverage. I don't mind having all features from the original product. The SWF revision will be the PRODUCTION-201707041014-428081343, no particular reason.

And about actors?
By the way I won't use the actor model (discussion about on page two). On my researches I proved that actors is really effective for backend servers, it can handle about 160k requests per second. Some graphs from Microsoft Orleans:
https://image.prntscr.com/image/EsGH...-oULAcR7g.jpeghttps://image.prntscr.com/image/FyQ0...wkYcx4FbQ.jpeg
But it isn't the most practical solution for a retro and there isn't need for it. So I will be using the traditional architecture.

Cassandra
And you didn't read wrong. I've been working with Cassandra in a startup on the last months, and it's been great. Cassandra employs many mechanisms for fault tolerance and the administration is easy, since is a homogenous system.
Then I'm 70% sure that oreo will use cassandra.

I created the thread in order to make contributions possible, then feel free to contribute! and you can expect a regular inactivity because I'm on high school. Nonetheless, I hope that the thread stays open for some time.

Checkout the repository: https://github.com/lai0n/oreo

Regards,
Guilherme Araújo

Interesting choice of name, as it's the same as AMD's (Advanced Micro Devices) product lineup for their new processors. I'm assuming that's where you got the name from?

Regardless, good luck. A Node server looks interesting, I'll keep my eye on it. :):

An emulator on node is interesting indeed, I will be following your great friend project!

Any particular reason for that SWF revision?

Quote:

---

Originally Posted by lai0n

And then, make it scalable

---

It's the wrong way around. Just saying.

Quote:

---

Originally Posted by The General

Any particular reason for that SWF revision?

---

Is the SWF that i have on my PC.

But if a better suggestion come, I can change it.

Is there a reason why you use plain JavaScript?

You should look into TypeScript (with their editor plugin) to make your live more easy.

Quote:

---

Originally Posted by Joopie

Is there a reason why you use plain JavaScript?

You should look into TypeScript (with their editor plugin) to make your live more easy.

---

I haven't think about this before. A good suggestion, maybe i will move to it.

Thanks @Joopie

- - - Updated - - -

Meeting on TeamViewer, updating the firsts things
m81-717-452

You should definitely consider typescript for large scale js applications, it will save you tons of time and will greatly improve workflow with IDE features much like visual studio has (you can even write ts in vs with most of its features).

Typesript compiles back to javascript, so there's really no difference for anyone other than the developer. You can also choose to compile into different versions of javascript.

here's a great video to learn more about it

Well, I'm hesitating some things. First, what is better: compile typescript onto ES6 or ES5?
Second, use rollup.js or not. Rollup compiles small pieces of code into a single file more larger and complex

What do you think about this?

https://github.com/jadenmitchell/Habbo

Perfect example by one of the better Node developers in the community if you need any ideas on some things

Quote:

---

Originally Posted by lai0n

Well, I'm hesitating some things. First, what is better: compile typescript onto ES6 or ES5?
Second, use rollup.js or not. Rollup compiles small pieces of code into a single file more larger and complex

What do you think about this?

---

As you're using NodeJS you should compile it to ES6.
And I dont think you need to use Rollup...

- - - Updated - - -

Quote:

---

Originally Posted by LeChris

https://github.com/jadenmitchell/Habbo

Perfect example by one of the better Node developers in the community if you need any ideas on some things

---

I wouldn't say that example is "perfect".

Quote:

---

Originally Posted by Joopie

As you're using NodeJS you should compile it to ES6.
And I dont think you need to use Rollup...

- - - Updated - - -



I wouldn't say that example is "perfect".

---

It's by far better than any of the retarded attempts at a HTML5 one in Node, and he puts quite of bit of research into things he does. By javascript standards and knowledge from back-end js it's a good example to use when looking into it.

(Only thing I would attack him on is not using ES6, which would make the code a lot easier to read and work with)

Quote:

---

Originally Posted by LeChris

It's by far better than any of the retarded attempts at a HTML5 one in Node, and he puts quite of bit of research into things he does. By javascript standards and knowledge from back-end js it's a good example to use when looking into it.

(Only thing I would attack him on is not using ES6, which would make the code a lot easier to read and work with)

---

You sound angry, can you not understand non ES6 JS? Stop taking the internet so seriously mate

Thread closed.

When you provide at least some form of proof that there is actual development happening (code snippets, screenshots, etc), contact me and I'll have the thread reopened again.

Project has been re-opened, with some changes. I'll be developing in Kotlin now
Kotlin is a great fit for developing server-side applications, coroutines, expressiveness bla bla bla

The revision has been upgraded from PRODUCTION version 2016 to 2017

Currently I'm writing the build properties (gradle)

Code:

---

group 'com.laion'
version '0.1.0'

buildscript {
    ext.kotlin_version = '1.1.2'

    repositories {
        mavenCentral()
    }

    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

apply plugin: 'kotlin'
apply plugin: 'application'

mainClassName = "main"

repositories {
    mavenCentral()
}

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
}

---

Nice to see the use of a language like Kotlin, good luck! (Looking into using Kotlin in an app I'm developing)

Change-log:
° Working in a Actor System (Orbit)
° Updated some things on github

Snippets coming soon

Building interactive services that are scalable and reliable is pretty hard. Interactivity imposes strict constraints on availability and latency, as that directly impacts endused experience. To support a large number of concurrent user sessions, high throughput is essential.

Then I decided to use a virtual actor framework, Orbit. This would avoid me use low-level concurrency constructs (The famous atomics and locks) and not think about memory visibility issues.

But the netty is multi-threaded under the hood. So, the use netty and orbit don't make sense, or do?

Researches about virtual actors take long hours and are complicated.
I hope you understand why I'm not coding now.

You're making it yourself overly complicated...

Quote:

---

Originally Posted by The General

You're making it yourself overly complicated...

---

What would you do? Sir General

I'd suggest sticking to a more traditional monolithic architecture rather than making it horizontally scalable. It's really not needed.. Unless the aim of your project isn't necessarily to create a full habbo emulator and is more to do with learning new architectures then go ahead and use Orbit, I've messed with it in the past and it really is a cool library.

I thought a (maybe) efficient method: On socket connect (managed by netty handler), an observer is created and written to an actor persistent state. On socket text, the client packet is decoded and is notified a equivalent server packet to the observer. Then the observer send the server packet do client.
Something like that

Code:

---

observer = object : ChatObserver() {
    override fun receiveMessage(message: ServerMessageDto): Task<Void> {
        // Transform the ServerMessageDto to buffer format
        buffer = message.toBuffer()

        ctx.write(buffer)
        ctx.flush()
    }
}

---

Quote:

---

Originally Posted by Leon

I'd suggest sticking to a more traditional monolithic architecture rather than making it horizontally scalable. It's really not needed.. Unless the aim of your project isn't necessarily to create a full habbo emulator and is more to do with learning new architectures then go ahead and use Orbit, I've messed with it in the past and it really is a cool library.

---

I don't give a fuck to Habbo. My unique aim is improve my knowledge

Quote:

---

Originally Posted by lai0n

I thought a (maybe) efficient method: On socket connect (managed by netty handler), an observer is created and written to an actor persistent state. On socket text, the client packet is decoded and is notified a equivalent server packet to the observer. Then the observer send the server packet do client.
Something like that

Code:

---

observer = object : ChatObserver() {
    override fun receiveMessage(message: ServerMessageDto): Task<Void> {
        // Transform the ServerMessageDto to buffer format
        buffer = message.toBuffer()

        ctx.write(buffer)
        ctx.flush()
    }
}

---

I don't give a fuck to Habbo. My unique aim is improve my knowledge

---

At least you're completely honest. +1
Good luck!

Quote:

---

Originally Posted by lai0n

What would you do? Sir General

---

Keep it simple and stupid unless there is a need for it, which there isn't.

Quote:

---

Originally Posted by lai0n

I thought a (maybe) efficient method: On socket connect (managed by netty handler), an observer is created and written to an actor persistent state. On socket text, the client packet is decoded and is notified a equivalent server packet to the observer. Then the observer send the server packet do client.

---

Might've changed since I was last filled in, but this sounds very similar to Sulake's current architecture. They use effectively stateless TCP frontends that convert the game messages to be handled by observers in the main game server (which itself is multiple components).

It's a great way to scale, but there are some overhead penalties to doing it like that. Not the most practical solution for a small-scale retro, but it sounds like a fun learning experience. Good luck with the project!

Quote:

---

Originally Posted by scottstamp851

Might've changed since I was last filled in, but this sounds very similar to Sulake's current architecture. They use effectively stateless TCP frontends that convert the game messages to be handled by observers in the main game server (which itself is multiple components).

It's a great way to scale, but there are some overhead penalties to doing it like that. Not the most practical solution for a small-scale retro, but it sounds like a fun learning experience. Good luck with the project!

---

For people who are interested in the article about the architecture, link: http://forum.ragezone.com/f801/habbo...ticle-1051918/

Pretty interesting article to read, it's 14 pages long.

Yeah and considering its from 2000, was already pretty remarkable back then.

Quote:

---

Originally Posted by The General

Yeah and considering its from 2000, was already pretty remarkable back then.

---

Once they decided to run at scale, this model makes a lot of sense. It's not an uncommon design for HA and scalability. Agreed though, it was impressive for what it was.

** worth noting, a lot of the technologies for doing this, with the services they were using, were bleeding edge or developed internally. The fact that it didn't explode more often is awesome.


Sent from my iPhone using Tapatalk

They basically invented their own wheel.

Change-log

• Continuous integration
• Simple packet decoder
• Set upped slf4j-log4j
• Fixed Unrecognized Windows Sockets error (#264)

Well. I've been working on more research. Sometimes with help of a Microsoft engineer mate
Some graphs which prove the actor model efficiency on servers:
https://image.prntscr.com/image/EsGH...-oULAcR7g.jpeghttps://image.prntscr.com/image/FyQ0...wkYcx4FbQ.jpeg
Source: Microsoft Orleans

And I noticed on tests that orbit allows run the service at very high CPU utilization. I have run load tests for couple hours at 90+% CPU utilization without any instability and low latency. I don't know if this is good for Habbo servers, but whatever.
And I designed a base structure for the service
https://image.prntscr.com/image/9czs...mNlz4vdTA.jpeg

- - - Updated - - -

On my eyes, actors is the perfect choice.
Implement it on a kotlin server will be the hardest thing that I'll do
but is totally useless. Which Habbo server needs this?
Maybe I will only use netty.

I'm sorry for the lack of updating. I was busy with school things
I will start committing this sunday
And I'll not use actors

Change-log:
Thread updated.
Repository moved.

Project closed. I'm really busy with school and my startup
Searching to a apartment to rent, so much thing.
Sorry guys.

Thread closed.

Please don't hesitate to private message me, or another moderator within this section to reopen this thread.