Our testings have shown that we are able to improve connection speeds by an average of 5.4 seconds using a common 512KB down stream 256KB up stream broadband line. We are pretty excited about this new improvement and hope that this new and improved technology will help better improve your experience on Hiitch. Therefore as an advance warning, you might want to take this into consideration in regard to your private network implementations of the Hiitch platform.

Do feel free to contact us if you have any questions, collaboration proposals or need better support from us with regard to your own network implementations using our platform.

Hiitch introduces new features for different virtual networks to merge so that their members can communicate with each other while maintaining separate or shared resources such as instant messaging (IM), news broadcast, community live boards and etc. It will allow the administrator to create totally separated virtual networks and/or merging those that may require their members to interact within a single physical server to form a larger network. The main idea is to give a greater degree of control, flexibility and privacy by defining distinct network groups and their resources but still allow members from different groups to mix and match when desired.

Members of virtual networks that are standalone can only communicate among their own registered members and access resources such as IM, news broadcast, community live boards and etc that belong to their own network. Hence these standalone networks are considered totally private and isolated. Shared virtual networks allow access from members of different virtual networks based on separate individual network access control lists. Future developments will include support for these features across different physical servers.

Hiitch now supports virtual networks on a single server. What this basically means is that you can now host multiple distinct desktop social networks on a single Hiitch server. The main advantage of this new feature is sharing and reducing both hardware and bandwidth cost. This new feature is useful when you have distinct social groups which you may want to keep separated without running multiple servers. The cool part about our virtual network feature is that a new network can be added while the other existing networks are up and running at the same time. No reboots, no need to reconfigure or restart the server.

The Hiitch server can accept runtime administration instructions such as adding a new network, removing an existing user and so on while the server is still actively running. These runtime administration instructions are just simple XML files that tells the server what to do when an instruction is issued. Issuing an instruction is as easy as placing the XML instruction file into the runtime instruction folder of the server’s setup directory.

Our New Networking Services

With the introduction of this new virtual networking feature, we are also planning to launch our private network services soon. These services will allow your company/club/organization to purchase a dedicated network from us for a low monthly fee. We will setup and manage everything for you such as hardware, bandwidth, security and upgrade & maintenance. Hence everything is handled for your company/club/organization and there is no effort from your part or the need for any dedicated manpower such as programmers, geeks and administrators. Do let us know if you are interested in purchasing such a service.

It has been quite a while since our last post, here’s a quick update on what we are doing right now. Besides bug fixing, we have upgraded our server to improve the overall performance of Hiitch. Everything seems whole lot faster now.

Over the next few months, we will be simplifing the procedure for you to set up your own network with Hiitch. This significant improvement will allow you to set up your own niche community in just a few quick steps. On top of that, we will start a market place and invite developers to build and sell features add-on for Hiitch. Lastly an overhaul of our main website, we have been receiving alot of criticism about our website and we hear you.

As you can see, lots of exciting things are about to happen. Do subscribe to our blog for the latest update.

Others]]> http://www.hiitch.com/blog/2007/08/31/patent-pending-hairstyle/feed/ http://www.hiitch.com/blog/2007/08/25/hiitch-on-killerstartupscom/ http://www.hiitch.com/blog/2007/08/25/hiitch-on-killerstartupscom/#comments Sat, 25 Aug 2007 05:05:44 +0000 Adam Soh killerstartupsNews http://www.hiitch.com/blog/2007/08/25/hiitch-on-killerstartupscom/ 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.

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.