Lightwave - A Scala server

[ovflowd]

@Setffchef awesome work!!!

 

[steffchef]

I visualized a micro-service architecture that I think could work.

Regarding the shockwave server, I introduced a message handler that routes client messages to specific handlers, so that I can eventually create multiple instances of handlers that are requested more frequently than others (FrontpageHandler > ModerationHandler, etc).

By the way I created a simple player service that handles the authentication of players as well, even though I'm not sure whether I should add a specific service that authenticates them by passwords and SSO tickets (probably not?).

Cheers,
Steve Winfield

 

[ovflowd]

Woah steffchef you're really doing things in the right way.

That's really awesome. I'm wondering if you will add API Documentation, Class Documentation and also release those Software Artifacts for common public.

 

[steffchef]

I'm wondering if you will add API Documentation, Class Documentation and also release those Software Artifacts for common public.

What kind of documentation? I think the majority of the code is self-documenting (if you're familiar with the framework), although I'm trying to write more detailed comments from time to time.

There's already a public repository (as mentioned in the first post):

You must be registered to see links

Cheers,

 

[Cankiee]

@steffchef check out

You must be registered to see links

 

[SuklaaVene]

@steffchef check out

You must be registered to see links

Its not running Lightwave, thats my own emulator called Skylight.

 

[steffchef]

steffchef check out

You must be registered to see links

Might be another server that aims multi-version support.

That's not my target though, it's rather creating an out-scaling server with a microservice-like architecture. However, the feature is a great way of demonstrating the opportunities and ideas behind it.

Cheers,

 

[Joopie]

It might be a wrong assumption. However I prefer to say it anyway just to be sure.

Looking at your diagram and your code I get the feeling that you're creating actors based on world objects. For example, every room is a actor. At first this seems logical to do, however this wont scale. Instead actors should be made based on tasks.

Imagine having a hotel with 10 rooms. And there are 500 people spread out over the rooms. This would normally just fine, because the load is balanced. Now lets say that suddenly 400 people want to enter a single room. The other 9 rooms still works optimal, but what about that one room with 400 people more in it? Suddenly that one actor has to process allot of messages. And eventually resulting in lagg, because, as of how actors work, they process messages one by one.

The solution would be to make actors based on tasks, instead of world objects (which may be problematic as that would change your design drastically).

I'm not a pro at this, but I hope, even if my assumption is wrong, you find this usefull.
I'd like to hear your input on this thought!

[STRIKE]Let me also search a blog post about this subject I read a while ago![/STRIKE]

The blog post explaining in more depth the situation, problem and solution of this subject:

You must be registered to see links

.

 

[The General]

Think you are planning to much and hoping too much that the community is going to contribute to your project which in all honesty is quite unlikely to happen.

Ofcourse I hope you will proof me wrong but I think this wont be completed or even get to a stage thats production ready.

Goodluck though.

 

[pel]

Think you are planning to much and hoping too much that the community is going to contribute to your project which in all honesty is quite unlikely to happen.

Ofcourse I hope you will proof me wrong but I think this wont be completed or even get to a stage thats production ready.

Goodluck though.

Like your C++ Emulator Sirius? jk jk, can agree with all of your points.

 

[steffchef]

Now lets say that suddenly 400 people want to enter a single room. The other 9 rooms still works optimal, but what about that one room with 400 people more in it? Suddenly that one actor has to process allot of messages. And eventually resulting in lagg, because, as of how actors work, they process messages one by one.

This scenario is unlikely to happen because there is a maximum of player that can enter the room. Theoretically, without the maximum, the client itself will lag at some point anyway (quite similar to a point I made earlier - http://forum.ragezone.com/f331/lightwave-scala-server-1123323-post8739758/#post8739758). So, it's actually scalable due to the fact that there is no room setting for "unlimited" players. Additionally, there is not just a room actor, but an actor for every entity, so they are distributed across the whole service.

Think you are planning to much and hoping too much that the community is going to contribute to your project which in all honesty is quite unlikely to happen.
Ofcourse I hope you will proof me wrong but I think this wont be completed or even get to a stage thats production ready.

Community contribution doesn't matter too much to me. As I have already mentioned in the first post, it's all about fun. It may come as a surprise to some people, but programming can still be a hobby despite having a tech job. Sometimes I am just up for some coding and private open source projects.

Cheers,
Steve Winfield

 

[steffchef]

Started to work on the entity walking functionality. I'm trying to avoid a game loop and use a scheduler instead

Got a simple implementation done. Sometimes though, it looks like it's stuttering at a walking speed of 490ms-510ms per tile. There are old-school servers that set a speed of 470ms.. Which one is right? (or does it need a consistent 500ms?)

You must be registered to see links

Cheers,
Steve Winfield

 

[Quackster]

Started to work on the entity walking functionality. I'm trying to avoid a game loop and use a scheduler instead

Got a simple implementation done. Sometimes though, it looks like it's stuttering at a walking speed of 490ms-510ms per tile. There are old-school servers that set a speed of 470ms.. Which one is right? (or does it need a consistent 500ms?)

You must be registered to see links

Cheers,
Steve Winfield

Aye, I had the same problem with my project, the part where you mentioned

I'm trying to avoid a game loop and use a scheduler instead

Basically, there was no implementation in C++ or any library that could imitate

You must be registered to see links

, which is pretty much perfect for queuing walking tasks.

My boy Leon gave me some advice and basically said, the way the ExecutorService works is that you have a single blocking queue, and then you have a defined number of threads which will run a task from the blocking queue.

Once that task is chosen, it will block that thread until the task is completed, and then it will loop until another task is available

So, here's some sample code from Icarus which I think could help you (surely something similar can be done in Scala, right?)

(from

You must be registered to see links

)

ExecutorService::ExecutorService(int threads, std::chrono::milliseconds duration) : duration(duration) {

    for (int i = 0; i < threads; i++) {
        if (this->running) {
            this->threads.push_back(new std::thread(&ExecutorService::tick, this));
        }
    }
}

void ExecutorService::tick() {

    while (this->running) {

        std::shared_ptr<Runnable> runnable = this->tasks.pop();

        if (runnable != nullptr) {
            std::this_thread::sleep_for(this->duration);
            runnable->run();
        }
    }
}

 

[steffchef]

Once that task is chosen, it will block that thread until the task is completed..

This is already implemented (behind the scenes) by Akka as we're dealing with the actor model.

Actually, the Akka Scheduler (

You must be registered to see links

) which internally uses the HashedWheelTimer of Netty, seems to do a great job. As it does not execute tasks at the exact time, I had to change the tick duration in order to make it more accurate (now it's a consistent 500-503ms).

Cheers,

 

[steffchef]

I'm kinda back! Lately, I implemented an A-Star pathfinder and improved some code. Additionally, I created an r63 (2011) front-end module that I called "lightwave-uber" (just because it supports the same client as uber used to). As there is no Shockwave support on Ubuntu, I have to use a virtual machine when testing out the shockwave stuff. Therefore, the v18 client is quite laggy, so that I'm gonna test further performance stuff on the r63 client instead.



Cheers,

 

[Quackster]

Just wondering are going to support the Habbo V1 version? AFAIK it dates back to 2002.

I have almost all the protocol figured out except for the instant messaging packet where receive a message from a friend in the Habbo console.

 

[steffchef]

Just wondering are going to support the Habbo V1 version? AFAIK it dates back to 2002.

Now that Lightwave (more or less) supports two different versions, my current focus is on implementing the main components of a Habbo retro. Sooner or later, I might add support for v1. For now, though, I'd like to work on different components, such as furniture, the chat, etc.

In order to improve some specific functionalities in regards to performance, I would like to embed some stress and latency tests. Hopefully, that will happen soon as well.

Cheers,
Steve Winfield