Highly scalable asynchronous NIO reactor library. My gift to the community.

[Parabolika]

This has absolutely everything to do with how servers work. How does a server send/receive data to all the clients? Networking. What is this library? Very high-performance networking. I would estimate that it can very easily hold around 2k rs2 client connections, while putting hardly any stress on the underlying system. Standard reactor pattern has been tested and proven to be able to handle millions of connections through a light protocol (I believe this was a phone system and it sent/received voice data - I haven't done any research on this, I was told by a friend who is good at programming) and the only thing that will limit your server performance is the code you write on top of this networking. This is infact standard reactor pattern, but stepped up a notch to use cached thread pooling (other types of pooling are available via the AsynchronousIOFactory) to be much more scalable than standard reactor pattern. Believe me, any server framework written by a reasonable programmer on top of this library will easily be able to handle 2k clients, which is the limit the client can have per-world. I'm sure this networking library could easily scale to be able to run multiple worlds in one process (several thousand connections) without any problems.

Your first argument falls apart, because the protocol has already been created [by Jagex]. You are only creating an implementation of it, not, as you say, using a special 'light protocol to transfer voice'. And, secondly, unless the code currently in place was absolutely horrendous, then the performance limiting factor is most definitely the network. For roughly 2,000 players, any type of caching to immediately serve up connections/threads/etc. would be a complete waste of time and memory. Again, I do think you have done a great job with this, but some of your reasoning appears flawed to me.

[Brown]

That's a quote of the moment.

@Brown, don't even attempt to make your own framework unless it's using something rather then standard i/o.

Its made from this, hence I posted here

[cavallers]

nice release. wont use tho

[Brown]

nice release. wont use tho

You should.

[gnarly]

You should.

He dosn't know how.

[Brown]

He dosn't know how.

He should look at test.java.


---------- Post added at 06:47 AM ---------- Previous post was at 06:38 AM ----------

Hey.. Using the source files of this, I mean, without having them in a Library.. That will work perfectly fine aswell, right?

[Torque12]

Ooooooooooooooo ^

I'm still playing with this.

[blakeman8192]

Your first argument falls apart, because the protocol has already been created [by Jagex]. You are only creating an implementation of it, not, as you say, using a special 'light protocol to transfer voice'. And, secondly, unless the code currently in place was absolutely horrendous, then the performance limiting factor is most definitely the network. For roughly 2,000 players, any type of caching to immediately serve up connections/threads/etc. would be a complete waste of time and memory. Again, I do think you have done a great job with this, but some of your reasoning appears flawed to me.

Maybe you should look deeper through this library before you attempt to judge it, there is no protocol implemented in this networking facility, it is simply a library that performs highly scalable networking. I was saying that if you use this library, the networking will not be the limiting factor, unlike in winterlove servers. Also, I have run tests and cached thread pooling does in fact scale much better than fixed thread pooling. The main thing is that in this library threads are only created if all threads are currently busy and can't take the new event. However, threads will be re-used until they have been idle for 60 seconds or more, which can pretty much be seen as a form of recycling to avoid the overhead of mass thread creation and destruction.

He should look at test.java.


---------- Post added at 06:47 AM ---------- Previous post was at 06:38 AM ----------

Hey.. Using the source files of this, I mean, without having them in a Library.. That will work perfectly fine aswell, right?

Yes, it will work fine without the source files. I have just included the source as I heavily support the open source revolution.

[Brown]

Yes, it will work fine without the source files. I have just included the source as I heavily support the open source revolution.

Thank you.
Btw, hows OpenRS comming along?

[Parabolika]

Maybe you should look deeper through this library before you attempt to judge it, there is no protocol implemented in this networking facility, it is simply a library that performs highly scalable networking. I was saying that if you use this library, the networking will not be the limiting factor, unlike in winterlove servers. Also, I have run tests and cached thread pooling does in fact scale much better than fixed thread pooling. The main thing is that in this library threads are only created if all threads are currently busy and can't take the new event. However, threads will be re-used until they have been idle for 60 seconds or more, which can pretty much be seen as a form of recycling to avoid the overhead of mass thread creation and destruction.

But how can networking not be a limiting factor? Are you saying that instead, another component (CPU, memory?) is the new limiting factor? Just how much networking traffic does each client use? And, I was saying that Runescape's protocol has already been established, so the amount of data flowing through the pipes will remain the same, NIO or not, this or not. I'm saying that recycling threads will have a minimal affect when network latency is so high.