Wednesday, December 26, 2007

Packet system

The server can now handle packets! (theoretically, anyway...)

But I guess I need to fill you in on the server program first, because I haven't said anything yet!

I'm writing the INHRPG server program in C++, as a Windows application. The network code uses Winsock2. Yes I know, "eww Windows! use Linux!" - well guess what? Windows is better in this case! I was originally planning to make the server program as a Linux program for best performance, but it turns out Winsock has this cool thing called I/O Completion Ports that has no equal on the Linux platform. It is very high-performance, and is multi-threaded! If I write my server correctly (and I plan to!), we will be able to get linear processing speed increases by adding more processor cores - in other words, upgrading from a dual-core to a quad-core processor would result in 2x the throughput, which isn't always the case in normal computing applications.

Sounds great, right? Well, it's a little complicated, but I spent time researching and figuring it out from the very little documentation available, and I now have a server that can accept connections, keep track of them, and disconnect them. Theoretically, it could handle thousands of users; that is, if my cable line were able to handle that many! But for now it has only been tested with some localhost telnet prompts.

So then the next step was to add a "reaper" thread. This is a part of the program that wakes up every few seconds and kills idle connections - connections that haven't received data for x time (right now I have it set to 10 seconds, but I may raise or lower it in production). It was a pretty simple change, although I had a few funny bugs and even a heap corruption error resulting in bad closing of clients. But anyway, in the end it all got sorted out, and it works great!

Next step: implement packets. Until now, it had just been a stream. For testing, the server would output all data sent to it. So for instance, I would open a telnet and connect, and then type "asdf" and the server log would show "asdf" (and then ~10 seconds would pass, and the connection would be 'reaped'). There was no persistence of data, which is very important.

So now I have implemented my packet scheme. It's a pretty standard packet scheme but I'm proud of it, cause it was kinda tough to add in... Anyways, in theory it should work great, but now I have to get the client up to speed so that I can actually test the server!

So, in conclusion, the server app has made considerable progress, it can now THEORETICALLY receive packets, so its development is on hold until I develop the client enough to be able to send and receive packets with the server. It'll probably be a few weeks until my next update, as I get the client working and iron out the bugs that I know my server app has. (that's why I keep saying THEORETICALLY!)

Oh, I almost forgot... If you would like to comment, go right ahead. I would love to hear from people who have been watching my wiki and this blog, or from people who have some sort of questions, comments, input, anything - if that's you, use the comment feature of this blog or the discussion feature of the wiki!

See you in a few weeks, when the client and server can connect and send test packets - and then the next step will be storing character data and logging in/out! Exciting! :)

No comments: