Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Welcome to our site

Take a moment to join our board

Leaderboard


Popular Content

Showing content with the highest reputation on 07/27/2018 in all areas

  1. 2 points
    Greetings everyone, my names Dylan but Xori is my persona in the Conquer Online world. I ran a few servers known as AEO(Acid Estox) and Project Immunity which did pretty well for what they were. I've been out of the game for the past couple years due to getting married and spawning my lovely daughter, but I have lurked in the shadows trying to stay up to date as well as I could with everything going on. I'm glad to announce that I am back and have been studying a few languages and working on a few projects in Unity3d in which more information on those are soon to come. Conquer Online has always had the effect of dragging me back after all these years. I started playing back in 2004 and still remember creating my first Trojan and adventuring around when then I stumbled on-to the Training Grounds, something I have never seen in a game before. Knowing I was able to play at my convenience and still have the connection of my character progressing while I was away made the game so appealing to me and I'm not sure why. I eventually grew bored years later with realizing I would never progress fast enough to compete with the bulkers and was introduced to a private server (Conquer Underground). It was here my interest and love for the game was relived, I was able to achieve everything I had wanted in-game without the need to spend thousands of dollars or hours of time. The server eventually started to die sadly and I wanted nothing more but to re-create the server in which brought me and many others much enjoyment so I studied and researched and stumbled onto EPVP/4Botters. Between the two networks I was able to set-up my own server and began bringing all my friends to join. Shockingly the server outgrew my hosting capabilities of using my person computer and the help of ole "Hamachi" and I eventually had to shut the server down and re-evaluate the situation. During that process I stumbled upon a server called Acid Co and found my love for dueling with Fast Blade & Scent Sword. Sadly all good things die as the server eventually shut down.. And then a spark hit me.. I decided to create my own PVP server and gave it my own twist with the ability of leveling up and raiding bosses with high risk pvp battles. And thus, AEO was born. It received much backlash due to the close name resemblance as Acid Co but that did not stop the success of the server. Hundreds of players flocked in playing daily and it was wondrous. But every great thing comes to an end. I had poor judgment and made some bad decision in which lead the downfall of the server. But after all these years I've still managed to keep close contact with quite a few in the community and have made some new friends as well. I'm glad to be a part of this new venture and rebirth to the community and have very high hopes for it. Spirited has created something great here, and I feel lucky to have the chance to build this community with you all and everyone to come. Thanks for reading! -Xori
  2. 1 point
    First Glance At first glace, System.IO.Pipelines appears to be an interesting solution for reducing the complexity of server sockets and efficient memory management. Without going into any details, the blog post suggests that Pipelines could provide an application with higher performance and a better / less complex server architecture. In this topic, I explore that idea using a Conquer Online server as a demo. Architecture What isn't mentioned in the blog post is the general architectures supported by Pipelines. The only workflow promoted by Pipelines via the blog post is an asynchronous one, where memory is written to asynchronously and read from asynchronously using two separate tasks. This scales nicely for a single data source, such as a single TCP socket accepting RPC; however, multiple tasks processing multiple data sources from multiple clients does not scale. A queue needs to be inserted for managing requests appropriately; therefore, two tasks per client connection just for receiving data in sequence doesn't seem appropriate. Rather, two tasks working asynchronously using a pipeline as a channel is overkill. That's the job of worker roles that dequeue work. A second workflow is promoted through the API for synchronous reads and writes. An asynchronous socket system could synchronously manage memory for a single asynchronous callback operation. This seems like the best approach for managing data request from multiple data sources. That would be one task per client managing receives. Performance For this test, Pipelines was implemented for synchronous memory management, which would be the most likely use case for a high performing game server that manages data using a worker role and queue. When analyzing performance, I wanted to see if it were any better than just keeping a fixed length buffer, such as in the case for SocketAsyncEventArgs. Since we're using Pipelines for synchronous memory management, the framework becomes simply weighed down by thread safety. Therefore, the obvious answer is that it shouldn't perform better than a fixed length array, and it doesn't. Pipelines takes ~41000 ticks while a fixed length buffer takes ~1800 ticks (tick count includes ReceiveAsync, which accepts and uses the buffer from both tests). Offerings So, besides performance, what else might Pipelines offer programs that wish to use the framework for synchronous memory management? The first answer that comes to mind is inherent in the question: memory management. Pipeline memory blocks grow as needed using an initial size hint. Received data is copied from a 2048 byte buffer to the dynamic memory buffer, and the application only processes bytes that it received. A maximum buffer size can also be specified by overriding the Pipe's MemoryPool option. All of this can be accomplished using fixed length Array Segments, and splitting on the received byte count. If you don't expect to be processing lots of packets per client, such as the case for Conquer Online's packets which are always smaller than 1024 bytes, then there's not a lot that Pipelines has to offer. Conclusion Although I feel that the Pipelines framework isn't helpful for the specific design of a game server, it does greatly simplify general worker role implementations for WCF. Rather than dealing with the complexity of Azure Queues, Microsoft Message Queuing, or implementing your own queue system using blob storage or memory for producer/consumer tasks, Pipelines offers a very clean and elegant solution for managing work from a single data source. Pipelines may also be helpful for multiple sources and a single, generic consumer, such as in the case of reading and processing map files for Conquer Online. Stepping back, it seems like Microsoft is learning from other languages such as Go, which offers the same functionality as a language primitive (channels) while also attempting to wrap and simplify its functionality. Hopefully we see more efforts like this in the future as these languages continue to compete against C#. With all of that said, what are your thoughts on my findings? Do you feel that my research was a good field test for Pipelines that went wrong, or did I take a wrong turn somewhere in the implementation? How have you worked with Pipelines so far, and has it helped simplify complex server code? I'd be curious to know. Thanks for reading. Edit: Corrections
  3. 1 point
    Wouldn't be possible without you, my friend. Welcome to the board, Xori. Damn, your avatar looks super cool as a circle.
×

Important Information

By using this site, you agree to our Terms of Use.