In the past 2 nights..

Here's my progress on SoftServer in the past two nights.

• 1st night: 802 lines of code.
• 1st day: 532 lines of code.
• 2nd night: 691 lines of code.

All of the code compiled and ran as expected. As of now I haven't ate really anything in around 10 hours, most of the time just trying to shove it down. I'd say I lost about 2-4 lbs one the course of these night and days -- but honestly I don't care enough to check.

Normally, you'd get tired and just do something else. However, you just feel like staying there until you've finished what you've set out to do. You stay there for hours and hours, time goes by quick when all of your focus is on that one goal. Hell, you don't even care about time anymore (the sun rising is wonderful evidence.)

It gets you stuck. Sometimes it gets you hours on cleaning. The reason why you get stuck is because you feel like you have a mission -- no matter how long it takes, you have to complete it. 

Now all I want to do is get on the computer. Start up that Debian on VirtualBox and hammer away on Code::Blocks.

The educational experience you can get from it is priceless: I learned a little bit of Template Meta-programming because I had a problem with static-typed parameters, I learned a little bit of std::map and the Standard Template Library because I wanted to organize my data better, and I rewrote two separate server applications just because I found out a more efficient way in handling and using packets.

I've actually been working on my general server software project SoftServer, the first beta build looked great. Then I pushed that build to GitHub and started another empty build again (and I don't know why). I have a bit of a compulsion to rewrite applications.

It was great the second time around, to recreate the architecture once more despite it being that you've already went through the process -- you can carefully re-walk your steps this time around (and make your code more pretty).

Everything has art in it. Even the most logical thing you could ever do, programming. There are many different ways I can design and build my server's architecture. Some ways more efficient than others. Other ways are not as great.

I used to "serialize" (I wouldn't even call it serialization) packets by separating them with semicolons. This was horrible practice, I knew it was -- but that's what you get for cutting fast corners in lieu of quality.

            My First Packet Idea: "JOIN_QUEUE;2;"

The integer after the first semicolon was to denote the queue's difficulty. The semicolons, themselves, are there for easy tokenization of the packet. I could separate JOIN_QUEUE and 2 with one simple function -- then use them as I please. 

Of course, it didn't go so well when I removed the semicolons (nothing to tokenize, except spaces). And it didn't help my collaborative partner much either when he had questions about sockets.

He had decided to tag along for this journey into networking with my project: User Datagram Transfer Protocol, UDTP. We were developing a simple scientific control, file transfer protocol using TCP, to compare with our own. When suddenly, during testing, bits and pieces of the packets were leaking to the next and the next.

After sitting for thirty minutes with both of us mumbling at the screen -- we had stumbled upon the Discovery Channel featuring a special program on these ravenous sockets...

                #define PACKET_SIZE 420

They were just reading way too much! Reading two or three packets as one whole packet. Ultimately, too fast for our sequential yet precise send() then read() architecture. To even further discourage our interest and belittle our knowledge in networking, Google had no shown results about this problem.

2 weeks later, we had met up in class again. Class was at 6:30pm.  I've forgotten to eat the entire day. He said that he had discovered something that would prove a remedy to our extreme disappointment.

I had told him I wasn't cognitive enough to comprehend anything. I was excited, of course, but the hunger was too much to bear. He suggested we go visit, "The Taco Truck." After one expensive taco, I reverted back to my normal self within half a minute or so.

He had gotten a piece of paper out since that's how he usually explains things. Telling me about structures and typecasting to character pointers (char*). Scribbling down so quick, I wasn't sure at first what he was saying. Until I realized where he aiming at -- he had solved the problem.

It had really made my day. I complimented him a countless number of times, sitting in the chairs of the ghetto outdoor dining scenery provided by yours truly, "The Taco Truck."  Such a small and silly thing to be happy about but that's what being a scientist (computer) is all about. 

He had told me that he was going to send me the source code on his experiment tomorrow. I couldn't wait though, and rushed home to test out the experiment myself.

1.  struct UDTP_Packet{
         PacketType type;
         char message[50];
     }sendPacket;

                                      2.   send(socket, (char*)&sendPacket, sizeof(UDTP_Packet));



          3. UDTP_Packet readPacket;

                   

                                      4. read(socket, (char*)&readPacket, sizeof(UDTP_Packet));



         5. readPacket.type;        readPacket.message;


Pink is the server. Red is the client. Don't you see how beautiful that is? Let me number it out for you.

1. Sockets knows exactly what size to read and send because both the client and server have the same UDTP_Packet struct using sizeof();
2. Being that send() and read() will only accept character pointers (char*) as a buffer argument. We can actually convert (typecasting) the UDTP_Packet struct to a character pointer (char*).
3. After sending the raw data, and receiving character pointer (char*) -- we can reassemble it back on the client's side by converting it back to the same UDTP_Packet struct.
4. You can actually access the members of readPacket with the dot member access operator. It "magically" went through the sockets of hell unharmed.

The world of networking and server architecture is confusing at first with having to play the role of two people (client and server). However, it is extremely rewarding and actually gets you thinking about the efficiency / scalability / optimization with all of your programs. Just think about it, you're actually making a server.

And no this is not Linux Server Administration, you are building it from the ground up with nothing but some experience and a little bit of interest.