Fig. 1. Attitude application, being executed in a Nokia N900 device
of the Remote Virtual Peripheral Framework, two principleswere kept in mind:
Keep the architecture simple and, if possible, withoutmodifying existing components.
Allow existing applications the usage of remote devices,without modifying their code (even, without recompilingthem, if they are executed in machines with the sameCPU architecture).Two versions of the framework have been developed, eachoperating at a different system level. The ﬁrst version workson top of the D-Bus architecture which shares D-Bus APIscorresponding to available peripherals between the two partic-ipating devices. The second version works at a lower level byexposing kernel character device interfaces for peripherals onboth sides. In the future, we would like to consolidate bothversions into a single uniﬁed framework.As a
proof of concept
, we have implemented the pro-posed frameworks on a Nokia N900 smartphone running theMaemo5 operating system. Maemo5 offers two interfaces tointeroperate with the embedded sensors and peripherals: a D-Bus API and a sysfs ﬁlesystem. For example, we can runapplications like
(Figure 1), that are designed to readacceleration information from a Nokia N900 device, in aLinux PC executing our Remote Virtual Peripheral framework (Figure 2). By utilizing our framework, the application doesnot need to be modiﬁed at all. Moreover, in this particular casethe
application is written in Python, so it is not evennecessary to recompile it to be executed in a x86 (Linux PC)or an ARM (N900) architecture.
In both framework versions, each device is exposed as aUPnP service. UPnP  takes advantage of existing stan-dardized protocols (IP, TCP, UDP, HTTP, SOAP and XML)to support automatic discovery of devices and services. Bothframeworks utilize UPnP to discover devices in the samenetwork with speciﬁc peripherals which can be accessedas remote virtual peripherals. For our implementation, we
Fig. 2. Attitude application, running in a PC but using our framework asthe input device to read the accelerometer information from a Nokia N900
have used the GUPnP (http://www.gupnp.org/) open sourceframework.
B. D-Bus based Framework
D-Bus  is an Interprocess Communication (IPC) system,designed to replace the CORBA and DCOP IPC mechanismsused before, respectively, in the GNOME and KDE desktopenvironments. It is a message bus system for GNU/Linuxsystems maintained by freedesktop.org. Nowadays, it is a keyelement in both desktop-based and mobile operating systemswhich use Linux. Speciﬁcally, D-Bus is used to realize 3 mainfunctions:
Exchange data between (system or user) processes.
Facilitate sending events and signals through the system(for example, an incoming call could mute the mediaplayer).
Invoke methods and request services from other objectsor applications.One important characteristic of D-Bus is that it uses mes-sages as the base unit for IPC, not a bit stream (in contrast withother IPC mechanisms). The message format is binary, typed,fully aligned and simple. Another important characteristic isthat it is a bus-based communication service. Applicationscan instantiate a private D-Bus to communicate, but the D-Bus architecture includes a message bus daemon that routesmessages from an application to one or more processes. Infact, there are two different buses, namely:
: This is a system-wide bus running atthe system level and is used to send events such as thepresence of new devices or the battery level.
: This is a per-user and per-sessiondaemon, used for general IPC among user applications.In context of the Remote Virtual Peripheral Framework the system bus is the one which is utilized as a channelfor transmitting information to/from the remote embeddedperipherals. In D-Bus messages are sent to objects, which areaddressed using path names. An object could implement one