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

[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 duck 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 duck 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-architecture-brief-history-article-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.

 

[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 (
  You must be registered to see links
  )

 

[lai0n]

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:

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

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.

 

[lai0n]

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

 

[lai0n]

Change-log:
Thread updated.
Repository moved.

 

[lai0n]

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

 

[Quackster]

Thread closed.

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