Quote:
Originally Posted by iBotx
That was hard lol.
Btw i want to admit that i'm using impulse's but a heavily modified one, the only reason i'm using that i'm busy with my academic studies. I don't intend to use it to run a server, it's juts for testing the new shit of co (writing the code and leaving it aside) so when i'm completely free i can code my own project and add these stuff directly. However, regarding impulse the project which i'm working on now my main objective was to replace the sockets , (the completely stupid threading system with tasks instead) , the screen system (which i failed cause i don't have enough knowledge on how it actually works) , the stupidest mysql handler ever seen to nHibernate.
|
Well, I'll give you the same advice that I gave Chris: if you have to use C# sockets with their managed thread pool, then limit the amount of system calls you make for receiving data. If you have a buffer with size 4 kb, then receive for that entire buffer and have a simple packet splitter that just moves a pointer across that buffer. When you start doing things like 2 receives per packet (one for the header, one for the body), you're going to fuck yourself over. The less stress you put on the socket system, the better your server is going to perform. System calls are expensive.
The screen system is rather easy, and I explained it a few times before (like here,
[Only registered and activated users can see links. Click Here To Register...]). Feel free to copy Phoenix's screen system. It can use improvements for efficiency, but it's still the most correct and most efficient public source implementation of a screen system. Be free to blatantly copy that if you feel necessary. I'll try adding the screen system to my wiki tonight or tomorrow.
Regarding NHibernate, it's dumb. Don't use NHibernate. Funny enough, I've gotten much better performance by relying on MySQL do to server-side caching than any object relational mapper. You can try Entity Framework (it's a simple implementation and it's pretty close in terms of efficiency to just using MySQL connectors. If you're not sure on how to handling threading and MySQL connections, use EF's code-first implementation.