The Technology Behind Hiitch
July 24th, 2007
This is the first of many technical articles that we will be releasing as we begin our work to bring Hiitch to you as promised in our previous blog postings. We will basically focus on the technology behind building a complete desktop social networking platform like Hiitch and how you can better utilize it for your own purposes without reinventing the wheel. Your suggestions and feedback will be greatly appreciated. You can also write to us about what you would like to know regarding the technologies behind Hiitch.

Hiitch is designed and developed to build a vibrant online community on the desktop. It delivers things of interest such as new people and events to the user by analyzing the user’s profile. It does automatic match making and has an array of features to allow users to interact online (eg. IM, file sharing, photo sharing, community forums, etc) at real time. All these are done securely on the desktop using technologies such as digital signature verification, SSL, data encryption and etc.
Another discussion on Hiitch’s security features can also be found from our previous posting:
Hiitch is basically (or partially) a client and server networking model. It is not intended to work with web proxies as they post as a big security risk and information leak. All communication done on Hiitch has to be done with direct connections to either the server or the client. A peer to peer model (p2p) for the clients is not used because not all networks allow p2p technologies to work correctly. Some networks hide their computers with transparent proxies to better protect their internal network which result in p2p connection problems. Other disadvantages include the fact that users must have enough know how to configure their home or private network to work with p2p solutions (port forwarding, firewall, DMZ and etc). Often than not a home or private network consists of a group of computers (LAN) and this will require multiple IP addresses not available to most home users. P2P is still a very good networking model and we are still experimenting on how best to combine both p2p models and the more traditional client server models to produce a best of both world solution.
Internally, Hiitch uses a technique similar to remote procedure call (RPC). We will discuss this in more detail in a separate post.
All communication data in Hiitch is transmitted using XML. This decision was to allow the client and server to become technology independent and open up possibilities to “just in time” instruction discoveries. So regardless of the programming language used to build the server or client, the only requirement for them (to communicate) is understanding XML. Each instruction(s) send from the client to the server is decrypted (when necessary), parsed and resolved into a set of runtime instructions. These instructions are then checked to see if they are allowed to run. Finally, the instructions are then executed on the server and any results available are returned to the client.
We hope this article will get you excited about Hiitch and the technology behind it. Our hope is that we can build a strong community of experts who are interested and willing to work with us to produce ground breaking social networking technologies for the generations ahead. Join our community today!
Filed under: Tips and Tricks, Features
by geek |

Tags:
[…] You can read more about Hiitch’s Network Connectivity Overview here. […]
↓ Quote | Posted August 1, 2007, 10:56 pm[…] Network Connection Overview […]
↓ Quote | Posted August 3, 2007, 2:06 pm1. You should be able to support secure connections via proxies, don’t rely on SSL for security, clients should send/receive all data by web get and post connections (persistent if possible), just be tricky with extra public key encryption, compression and network details to frustrate snoopers and impersonators i.e. a pull based architecture.
2. XML can have performance issues and it can be slow to process.
↓ Quote | Posted August 17, 2007, 3:31 amHi Infernoz,
We don’t mean to be rude in our rely here but it is important to answer some of your suggestions. Ultimately, we hope it makes a good discussion. Do keep in mind that Hiitch is not a web server nor does it implement the web protocols.
“1. You should be able to support secure connections via proxies,”
Proxies leak information and becomes a big security risk for private data. Unless we want to be anonymous, then we would want to use techniques like proxy chaining, which we agree. But unless the proxies belong to us, the chances of our client’s information falling into the hands of 3rd parties are extremely high. Snooping can be easily done on these external proxies by caching the information that goes in and out of them and those cached information can then be decrypted at a later time, if needed.
“don’t rely on SSL for security, clients should send/receive all data by web get and post connections (persistent if possible), just be tricky with extra public key encryption, compression and network details to frustrate snoopers and impersonators i.e. a pull based architecture.”
We don’t rely only on SSL. The key worry of SSL is on the server identity verification. We use digital signature verification and unique server IP to identify each network which will allow clients to connect only to their particular network. Your suggestions merely hope to slow down the hacker but does not attempt to solve the problem.
You can read more about our security features at http://www.hiitch.com/blog/2007/02/14/how-secure-is-hiitch.
By the way, get and post are for web servers and are suitable for the purpose in which they are designed. Hiitch requires more than what they can offer hence our approach uses techniques similar to RPC (remote procedure call).
“2. XML can have performance issues and it can be slow to process.”
Our testing has shown that a simple Hiitch session XML request can be completed in the range of 90 milliseconds on our entry class server (connection time included, LAN), which is fast enough for our purpose of use.
And yes, XML is slower to process, we agree. We have no doubt about that but as for causing performance issues, that will depend on what you are using it for. It is all about finding the best solution that meets our needs. In any solution there will be pros and cons but if the pros out weigh the cons for the purpose that we want to achieve than it is acceptable to us.
If we were concerned merely about performance issues only, than we will not even use TCP (hence, post and get) as our transport protocol. UDP is a far more faster protocol to use because it does not have the connection overheads of TCP.
Thanks for your interest to help make Hiitch better.
↓ Quote | Posted August 17, 2007, 11:27 am[…] Network Connection Overview […]
↓ Quote | Posted November 14, 2007, 4:54 pm