Ouch, we are been featured on the hit list of KillerStartups.com. Thanks Gonzalo for that little mention of us. Read the full review here.

Hiitch has now introduced voice mail to our social networking platform. You can now send voice mails to your family and friends right from your desktop. We have also introduced a new voice introduction feature on our member’s profile cards so that you can now listen to what they have to say in person. It is a totally cool feature!

We are also working on introducing VOIP (Internet Telephony) on Hiitch too but we have limited resources to implement it at the moment. Do stay tuned to us as we bring you more fun and interesting technology at your finger tips.

If you use Hiitch and want internet telephony on Hiitch for your family and friends, then give us a shout of encouragement here to work harder for you!

We have described the general server design and threading model in our last article. Today we will go under the hood to explore the engineering details of how data is transferred between the server and the client. On the high level, instruction requests are harvested in sets and queued for processing by the worker threads. The worker threads resolves the XML instruction requests into a set of executable instructions on the server and processes them after correctly authenticating the source. The complexity of this system is based on a simple but advanced communication protocol designed for today’s needs.

Communication Protocol
The communication protocol between the server and the client is in XML. The client aggregates a list of instructions that they want executed on the server and then transmits that to the server. The sequence of the execution is determined by the ordering of the client’s XML request, which is done bottom up. The last instruction at the bottom of the XML request is the first to be executed on the server, followed by the last second and so on. The format of the protocol is not entirely XML based. The protocol divides all the data received or send into two segments. The first segment hold the XML instruction, the second segment hold raw attachments, if any. Attachment segment may hold additional file contents that are not XML based (eg. binary data). The first 8 bytes or 64 bits dictate the total data block size. The second 4 bytes or 32 bits indicates the first segment size, the remaining data belong to the second segment.

This protocol design although simple will allow us to provide a basic mechanism to transfer vast amount of differing types of data depending on the XML instruction request defined by the first segment. You can view the first segment as the instruction manual to process the request or sets of requests and the second segment as any other additional data required to fulfill the request or sets of requests. It may seem that this protocol is nothing special on first inspection but we think otherwise. Many of the protocols used today (eg. web server) are done using fixed Id values and headers which are less flexible and robust. The reason is that these older protocols mainly focuses on the format of transferring data and stopped there. Data that we communicate to each other today demands more than just being transferred but also properly processed to have any real value.

A simple example will be a file transfer using this more advanced high level protocol. The first XML segment can define a file transfer indicating how big the file size is in the attachment, the file name, destination location and etc. The protocol can also handle multiple file transfers in a single request. This will then allow the server to save the file to some predefined location. The XML segment might also define a decompression instruction that will result in the transferred file being uncompressed at the end of the entire exchange. The XML segment might also further define what is to be done with the uncompressed data and etc. This results in a more flexible and robust system that can be self descriptive and automated at a high level.

If you use our work, we ask that you remember to give us the credit that we deserve. Our hope is to develop better technology through open sharing so that future generations can benefit. Research and development for newer and better technology is still in great need as our generation moves towards the digital age, so join us in this fight towards the cutting edge of information technology.

The Hiitch server is a multi-threaded application server that you can tune to scale it to your desired hardware setup. It also implements customizable security features that you can use to secure your own network’s integrity and privacy. Hence, understanding some of the key concepts in its design implementation is important. We will begin by describing the detail interaction process that goes on in the server that is unique to every individual Hiitch network implementation.

Server Interaction Process
Before any information is communicated between the client and the server, the clients will first request for the authenticity of the server. Each client has an associated digital certificate that ties it to a particular server. The client will then verify the digital signature to see if the content is coming from the intended server and proceed to send its confidential information to sign in to the server. This whole verification process is unique to each network. During the server installation process, our default script will assist you to generate a set of public and private key pair, also known as a digital certificate, that identifies your particular network. Without generating this digital certificate and exporting the cert to your clients, the integrity of your network can be easily compromised. Once the verification process is correctly completed, the clients will start a new secure session with the server.

Server Threading Model
Once a secure session has been authenticated and started on the server, its threading model kicks in. All clients requests are harvested and then independently processed by a pool of worker threads. You can tune and configure the total number of threads you want as socket harvesters and the number of worker threads attached to each socket harvester. The flexibility of the threading model will enable you to control the performance ratio between accepting requests and processing instructions on each server. Socket harvester threads are responsible for receiving incoming requests and then queue them up for processing by worker threads. Worker threads are responsible to resolve incoming requests to a combination of instructions and then processing those instructions to satisfy the requests. The result of this design is a very advance, efficient and scalable server that you can optimize with your dedicated hardware setup.

Server Performance Considerations
The Hiitch server was also designed to work with other techniques that can help you to easily and cheaply scale your network. A few of these techniques that you can use in combination are load balancing, network file system (NFS), high availability and etc. With a good amount of bandwidth, you can improve your social network performance by load balancing multiple Hiitch servers on a few old computers sharing their storage space using NFS. Hiitch servers will work seamlessly across the entire cluster of machines as if they were one single computer. High availability is a build in feature on Hiitch servers, although not extensive but it should be reasonable enough to meet your average needs.

Future Server Developments
Future developments will move toward a peer to peer (P2P) Hiitch servers system with clients that can connect across different networks securely and dynamically.

If you are interested to read more, other earlier technical articles about Hiitch can be found here.