iRemote Suite

  • Increase font size
  • Default font size
  • Decrease font size

iRemote Internals


This article gives brief introduction into Remote PC Suite and iRemote Suite concepts and architecture. It also contains mentioning of iRemote ideology, development trends and policies.

The main goal of the project is to build stable, fast, and secure platform for remote manipulation over desktops, laptops and servers by means of mobile devices. The project initially was not oriented to become open source for many reasons. The most significant is lack of legal support. Although it is not excluded absolutely, it is not going to happen soon.

But this project significantly differs from other proprietary projects. Another goal of it is to build open platform. This means that everyone can contribute to it or even extend it with support for another device or desktop OS. This goal can be achieved by passing through a couple of successive iterations. Here they are:

  1. Publicly available free application (platform demonstration).
  2. Open architecture.
  3. Open interaction protocol.
  4. Open Platform SDK.

The project has just entered second phase and moving forward rapidly.


Desktop – any Mac or PC computer (notebook or workstation, whatever).
Remote PC Suite – desktop server application.
iRemote Suite – application for mobile device.
Application – combination of Remote PC Suite and iRemote Suite.
iRemote Platform – is a core of the Application.
iRemote – project name surrounding all above mentioned components.

High Level Concepts

This section introduces iRemote Platform. iRemote Platform is a combination of interaction protocol and stacks of technologies, utilized on both desktop and mobile sides.

Undoubtedly, the most widespread method of distributed interaction between wired/wireless devices and workstations is TCP/IP. In most cases it means TCP/IP over WiFi, Ethernet or 3G, GPRS, EDGE. Most platforms hide these details from developers. The only thing, which can be determined, is whether host with specified IP address and port pair is available or not. And if it is, it does not matter, whether it is available directly (it created ad hoc WiFi network) or it is located in the other end of the world. iRemote Platform stands away from these details.

iRemote High Level

In case of mobile devices, it makes sense to pay attention to local wireless protocols (like Bluetooth) and even to data exchange by means of data cable. All these things lie outside of iRemote platform (at least for now). In any case, application is designed so, that it can be easily extended with another connection type.

Most software systems consist of lots of independent blocks. The way these blocks interact with each other is usually called interface or interaction protocol. Protocol design defines how the system is fast, stable and how extensible it is. There are a lot of remote desktop protocols. Most of them support typical operations for manipulating desktop from another desktop: screen sharing, mouse and keyboard manipulation. iRemote Platform is designed to provide users of mobile devices with the most convenient way to manipulate desktops. This task differs from general purpose manipulation over desktop from another desktop. When running remote control application on mobile device, user mostly expects to get convenient way to do certain task. The most requested feature is to be able to control particular application (like media player, slide show application, etc.) from mobile device. Most existing remote desktop protocols miss this feature. Here comes another significant reason for turning away from designing iRemote based on top of existing protocol. Lots of problems emerge on the way of extending it. One of the most significant is that, it is difficult and almost impossible to pass through changes submission procedure (it is true for most committees). Of course, it is not of prime importance, if both client and server are implemented within the project. But this nullifies all advantages of such approach.

That is why it was initially decided to provide users with desktop-side software responsible for interaction with connected devices and for interpreting all incoming commands.

Interaction between Remote PC Suite and iRemote Suite is implemented by means of custom binary protocol (over TCP/IP for now). This protocol has not been frozen yet. It is still in development even after iRemote Suite 1.2 is released. The reason for this is that, a number of application features grows, and it is almost impossible to forecast all potential cases beforehand. Even, the fact that it is binary is not final. It is subject to change in the next versions of the platform. The most significant advantage of binary protocol is that it is the most efficient from perspectives of traffic size and processor usage, when parsing incoming and formatting outgoing messages. This may be critical for most mobile devices and that is why this approach has been chosen for iRemote Platform 1.x.

One of the primary concepts of iRemote Platform is security. Speaking about iRemote environment, we should take into account, that private WiFi network is sooner an exception than a rule. In general any publicity accessible TCP/IP network can be sniffed. This causes necessarily to encrypt all traffic between distributed components of the system. iRemote Platform 1.x is missing encryption for a number of reasons. The primary one is that, this component is still in design and there is no sense to postpone platform development and intermediate releases until it is ready. iRemote is designed as component-based system. Its architecture is flexible. So, as soon as portable security (data encryption) module is ready, it will be integrated into the system with no pain.

iRemote Suite Internals

For now the only supported device platform is iPhone OS. This operating system is designed by Apple engineers based on Mac OS. With lots of significant differences, it is still Unix-like system from one point of view and Mac-like from another one. A combination of BSD sockets on low level (and a chance to utilize it in native applications) with high level Cocoa Touch UI opens up broad prospects for application designers.

iRemote design is based on the separation of object model and server interaction code from application UI. This does not mean that it lies in different directories. This separation implies using different stacks of technologies for UI and platform code and even different programming languages. The list of things, that actually made it possible, is given below:

  • GCC 4.x. Actually this is the most significant advantage of iPhone OS platform. This not only gives a chance to design and develop applications in C++, but it allows to utilize tons of libraries and tools, written in C++.

  • BSD sockets. This gives a chance to implement networking support with familiar API. Other networking APIs from Foundation or even Cocoa Touch levels of Cocoa are also good. It can be also wrapped and become base for the implementation of iPhone backend of cross-platform networking component. It is possible, but there are a couple of disadvantages of such approach. All these APIs are built on top of BSD sockets. This usually leads to performance overhead. It is clear even without benchmarking. The next reason is that it is rather difficult task to create good portable networking component. It is difficult not only because it is necessary to implement backend for each platform. It is not so simple to define good public interface, what is even much more important. All these things lead to turning towards BSD sockets based approach. To increase portability of the solution, it was decided to build networking component based on boost::asio. This is not just well designed library. This library has a good chance to become a part of C++ STD in nearest future.
  • POSIX concurrency. The situation with synchronization primitives provided by the platform is almost entirely matches the one explained above for networking problem. The decision was to look to the bottom of the stack of available concurrency APIs, and to use the lowest level one. The only difference from above mentioned approach (utilized for networking) is to implement wrapper for synchronization primitives without additional intermediate level (such as boost::thread).

All above explained conditions lead to the implementation of cross-platform library covering all networking and concurrency aspects. This library is called CommonKit. It is now an open source project hosted at Google Code. iRemote Platform is built on top of it on iPhoneOS, MacOS and Win32 platforms.

Another thing that should be mentioned here is application testing. Most issues and bugs are easy to detect and fix even, when running an application on simulator. But there are some cases, when an issue is reproduced only on device and only when it is unplugged. It is the most difficult, but not the only case, when standard debugger does not provide enough capabilities to find an error in the code. The most widespread example is debugging the code, which heavily utilizes concurrency. All these weak aspects of bug fixing process were simplified by introducing HieLog (Hierarchical Logging) library. This component delivers logs over TPC/IP and supports concurrent execution of different software fibers. The library was utilized only for debugging purposes and its code does not present in final assemblies. That is why it is not illustrated on the charts below. It is the second open source project, related to iRemote.

The next architectural decision concerns interaction in bounds of iRemote Suite. It is clearly seen that server should be able to notify UI on certain events as well as application should respond to user input accordingly. This was solved by introducing control interfaces on both platform and UI side. UI component, written in Objective C, is able to refer to native C++ control interfaces, provided by platform code, directly. Reverse interaction requires additional tool, that lies on UI side, accepts C++ calls from platform and translates it into Objective C messages. This also gives another advantage. This tool is responsible for delivering messages to UI components on main UI thread to avoid synchronization overhead on UI side. This is powered by - [NSObject performSelectorOnMainThread:withObject:waitUntilDone:] feature. Returning back to invocation of platform methods from UI code, the following should be taken into account. Platform code (server component, etc.) is designed to handle invocations from any of application threads. So neither UI nor any other application component should take care about synchronization, when making call to platform control interfaces.

iRemote Suite Concept

This chart illustrates most significant components and dependencies inside iRemote. This does not pretend to be full, of course, and uses free form notation. Detailed description of each block is not given. The reason for it is that this article is mostly introductory and should not be overloaded with such details.

Remote PC Suite Internals

As it is initially decided, Remote PC should provide user with simple and convenient control panel. Qt framework is chosen to power application UI. This decision was subsequently brought untold number of additional benefits, besides the obvious advantages of the library in comparison with its competitors.

Remote PC shares most architectural aspects with iRemote. The differences are illustrated on the chart below.

Remote PC Suite Concept

Remote PC is entirely written in C++. The only exception is an implementation of Hardware Provider backend for Mac OS platform. It contains pieces of Objective C code.


The project and the platform are in active development now. As it was already mentioned, mainstream of the project is designing open platform for turning mobile devices into remote controls over desktops. The closest step in this direction is porting platform code to Java environment. This is rather good estimation for all above mentioned concepts. In case of moving all code to another programming language, the only thing that is actually shifted is set of fundamental principles and high-level architectural decisions. If it is successfully done, these basic principles are seemed to be successful also.

What concerns Java, there are not so many options in this direction: pure J2ME, RIM BlackBerry and Google Android. Android platform is much more preferable as starting point here. Of course, lots of design work still must be done before coding actually starts. Two primary reasons for making this job well are: these platforms consist of entirely different stacks of technologies (in comparison with C++ based) and new code should be as much portable (within mobile Java world, of course) as possible.


CommonKit -
HieLog -


Copyright © 2009 Egor Pushkin
Copying or storing of any content for other than personal use is expressly prohibited without prior written permission from the author.
Contact me for more details on iRemote project:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it



What OS does your desktop run?