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

[Caustik]

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

[lai0n]

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

Snippets coming soon

[lai0n]

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.

[The General]

You're making it yourself overly complicated...

[lai0n]

You're making it yourself overly complicated...

What would you do? Sir General

[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.

[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

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'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

[pel]

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

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!

[The General]

What would you do? Sir General

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

[scottstamp851]

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!

[Eronisch]

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.

[The General]

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

[scottstamp851]

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

[The General]

They basically invented their own wheel.

[lai0n]

Change-log

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