Looking Back: SupaChat Server

As I develop the snap-in for SupaChat Server I mentioned last post, I'm finding a lot of issues with the software. Let's talk about it!

• SupaChat Server was started by me in sixth grade after my computers teacher told me to "do something with variables." It grew organically with minimal direction of what I wanted do actually have it do. I had created an incredibly lame "chat" application that worked by writing lines to a shared file before. SCS was my first time actually making networking work.
• It quickly became a serious effort. After a year or so, it grew into a pretty large thing. I even created a lobby for multiple server instances to meet potential clients in. Obviously, that part never ran, but the code worked.
• There's no multithreading or queuing. When a new client connects, the server gives it 5 seconds for each auth field and a few more for optional encryption information. During that time, execution is blocking, waiting for the client to respond. Therefore, while connections are being processed, no other information is being relayed.
• That said, everything worked surprisingly well. All the commands worked and the UI didn't even get too slow.
• I didn't know about the principle of keeping processing and UI separate. In the data module creatively named "Code", many references are made to things in frmMain, especially to update the user list. However, I do feel kind of proud of that thousand-line file; it got me into Black Hawk College's computer science program in eighth grade.
• Encryption was an afterthought. SCEC works perfectly fine, and I guess is secure if the attacker didn't hear the beginning, but it relies on people not knowing how the server chooses the key. (Hint: it's based on a very suspicious line in the introduction.)