Open Source Introduction to AllJoyn Project

download Open Source Introduction to AllJoyn Project

of 34

  • date post

  • Category


  • view

  • download


Embed Size (px)



Transcript of Open Source Introduction to AllJoyn Project

  • Open Source: An Introduction to the AllJoyn Project

    Greg BurnsSenior Director, Engineering, Qualcomm Innovation Center, Inc.

  • Agenda

    AllJoyn Overview Architecture and Concepts Security Framework Performance Considerations Code Example Q&A


  • AllJoyn Overview

  • What is AllJoyn?

    AllJoyn is a new proximity based mobile peer-to-peer software framework developed by Qualcomm Innovation

    Center, Inc. ("QuIC")


  • What we mean by Peer-to-Peer

    But, How Do You Find and painlessly connect

    to devices around you Discover services running on devices Adapt to devices coming and going Deal with different transports Interoperate across different

    operating systems Exchange information and services Provide reliable performance

    in wireless environments Ensure no one nearby maliciously

    hacks into your phone


    Simple Definition:Communicating withstuff around you without need for a server

  • Framework: Removing Barriers


    Performance Optimizations

    Transport/ OS Agnostic


    Managed Networking


    Developers write to a simple API

    * Supportforthcoming

    SessionsLower Latency

    Point to MultipointRaw-Data


    Data MarshallingAd-hoc networks




    BT / Wi-FiAndroid/Linux/

    Windows* Wi-Fi Direct

  • Fueling Innovation and Enabling New User Experiences








  • Why Develop AllJoyn?

    Simplify and extend device inter-communication capabilities

    Always-on always-connecting

    Fuel new and creative application usage models

    OS independent platform for peer-to-peer innovation

    Seed the peer-to-peer application ecosystem


    An Open Source Project

  • AllJoyn Open Source Project:

    Launched Jan. 2011 GitHub hosts source Apache 2.0 License


    Documentation SDK Tools Contribute Download Forums

  • Architecture Concepts

  • Architecture Overview

    AllJoyn is a distributed software bus Each device runs a bus daemon Applications communicate directly only with the daemon Daemons on each device communicate with daemons on other

    devices Daemons do message routing and namespace management

    Bus formation is ad hoc Based on proximal discovery Abstracts multiple discovery mechanisms

    Protocol is transport independent Ground-up implementation of the DBus wire-protocol with extensions Supports Wi-Fi and Bluetooth currently


  • Why the Dbus Wire Protocol?

    Why reinvent the wheel?

    IPC mechanisms used on many Linux distributions Deeply integrated with system services and session management Supports RPCs as well as unicast and multicast events

    Object oriented Objects, interfaces, methods, and properties

    Language neutral Bindings for C, Java, Python, Perl, etc.

    Message bus architecture RPC and events implemented as messages Daemon handles messaging routing between clients


  • DBus Compatibility

    Distributed Bus


    Distributed Bus


    Peer sessionsPeer sessionsService

    Advertisement & Discovery

    Service Advertisement

    & Discovery

    Device-to-device message routing

    Device-to-device message routing





    Header Compression

    Header Compression

    Message Expiration (TTL)

    Message Expiration (TTL)

    Raw Sessionsupport

    Raw Sessionsupport


    Topology management

    Topology management


    Object modelObject model

    Routing rulesRouting rules

    Client-bus authentication

    Client-bus authentication SignalsSignals

    Name spaceName space

    IntrospectionIntrospection Remote procedure callRemote

    procedure call



    DBus Compatibility

  • Message Types and Properties

    Serial numberfor matching method replies to method calls Senderautomatically inserted by AllJoyn Destinationnull for broadcast or multicast messages Object-pathpath to an object Interfaceinterface name implemented by named object Membermethod name or signal name Signaturespecifies argument types for data payload Session IDfor device-to-device communication Payloaddescribed by the signature

    1. Signalsasynchronous event broadcast, multicast, or point-to-point2. Method Callscall portion of an RPC3. Method Repliesreturn portion of an RPC4. Errorserror response to an RPC


  • Bus Attachments, Objects, Proxy Objects An application needs a Bus Attachment to communicate with the bus

    Bus Attachments provide a root (/) for the object hierarchy

    Bus Objects implement interfaces Bus Objects path names look like file paths, e.g. /org/AllJoyn/Games/chess Bus Object have methods than can be called remotely Bus Objects can emit signals

    Proxy Bus Objects are local representations of remote Bus Objects Applications use proxy bus objects to make method calls to remote objects


    Bus Attachment Bus Attachment

    BusObject Tree

    Application Application


    Event handler


  • Distributed Software Bus


    App X

    Device 1

    App Y


    App X

    Device 2


    App Y

    Device 3

    App Z


    Conceptually peers are applications, not devices.

    Applications communicatewith a local daemon.

    Daemons handle routing between devices.

    TCP or BluetoothLocal socket

  • Ad-hoc Bus Formation




    Actual discovery mechanism is transport dependent: On Wi-Fi a lightweight IP multicast protocol. On Bluetooth device discovery with EIR and SDP query. On Wi-Fi-Direct TBD.

    Find-Name request




    Find-Name request

    Client App Service App

  • Ad-hoc Bus Formation



    Once connected, daemons form single bus with shared namespace- Peers can discover when other peers join or leave bus- Peers can make RPC calls and send and receive events


    Peer Session

    Distributed Bus

    Client App Service App

    Daemon Daemon

    - Session reference counting keeps device-to-device connections alive- Multicast events can be sent to all peers in the session

  • Security Framework

  • Security Framework

    Authentication and encryption is app-to-app: The bus is not involved other than to route.

    Trust relationship established between the applications. Device pairing not required unless the transport requires it. In case of Bluetooth, AllJoyn does not normally trigger pairing.

    Security is enabled per-interface: Authentication and key exchange initiated on demand.

    Security-enabled interface: Authentication is required to make method calls. Authentication required to receive signals.


  • AllJoynDistributed Bus

    AllJoynDistributed Bus




    Security ModelAuthentication and Encryption

    Signals from a security-enabled interface are encrypted and authenticated

    Application can allow a mix of security-enabled and non-secure interfaces. Maintain own key storecan use password

    Method calls to security-enabled interface are encrypted and authenticated. If call encrypted, so is reply


    Key Store

    Key Store

    Key Store

  • Built-in Authentication Mechanisms

    Three mechanisms supported Mechanism negotiated using SASL protocol Application developer chooses which mechanism to use Algorithms adapted from TLS protocols per RFC 5246

    Pin-code Authentication with a single-use password Trust relationship is persistent

    Logon User name and password type Password required every time peers connect

    Certificate-based RSA public key authentication and X.509 certificates Trust relationship lasts while certificate valid


  • Encrypted Message

    Serial #

    Header length

    Body length

    Header fields

    Zero padding



    Endian flagVersion #Flag bits

    Message type

    Indicates message is encrypted

    The header and the body are authenticated using AES-CCM .

    The body (payload) is encrypted. The header is required for routing, so

    is authenticated but not encrypted. Structurally an encrypted message

    still conforms to the DBusspecification.


    0-7 bytes

    Body lengthbytes


  • Performance Considerations

  • Message Efficiency

    Time to live: Added for multi-player games and streaming where stale data is useless. Mainly applies to signals. Introduces a new message header field. Expired messages are silently discarded.

    Header compression: Significantly reduces the size of message headers. Intended for messages that are sent frequently. Allows short messages to fit into single-slot Bluetooth packets.

    Multipoint sessions: Bounds the scope of broadcast signals to session members. Provides mechanism for deciding when radios are no longer in use.


  • Direct Point-To-Point Bulk Data Exchange


    Removes overhead by providing direct access to underlying socket

    Application can read/write any data to the socket

    Removes overhead by providing direct access to underlying socket

    Application can read/write any data to the socket

    Raw Sessions

    1. AllJoyn sets up a peer-to-peer normal session

    2. Peers call daemon to obtain the file descriptor for socket

    3. Daemon returns open file descriptors to peers, closes session

    4. Session is gone but sockets remain open

    1. AllJoyn sets up a peer-to-peer normal session

    2. Peers call daemon to obtain the file descriptor for socket

    3. Daemon returns open file descriptors to peers, closes session

    4. Session is gone but sockets remain open


  • Code Snippets

  • Language Bindings

    Native implementation for AllJoyn is C++ Java binding is available for Android Binding for JavaScript is under development Considering bindings for C, Python, and Lua Object model is similar for all bindings

    Create a BusAttachment to connect to the bus Create BusInterfact(s) that will be implemented by BusObjects Create and register BusObject(s) with the BusAttachment BusObjects handle remote method calls and emit Signals Applications call methods on remote objects using

    ProxyBusObjects Applications register Signal handlers with BusAttachment


  • AllJoyn Hello World in Java*import org.alljoyn.bus.BusException;import org.alljoyn.bus.annotation.BusInterface;import org.alljoyn.bus.annotation.BusMethod;

    /** This interface implements a simple echo method that returns the same string* that is receives.*/

    @BusInterfacepublic interface EchoInterface {

    /** Echo a string.** inStr is the string to be echoed by the service, returns the echoed string.*/

    @BusMethod(signature="s, replySignature="s")public String Echo(String inStr) throws BusException;


    * Code snippets licensed under the Apache License, version 2.0


  • The Echo Service*public class Service implements EchoInterface, BusObject {

    public static void main(String[] args) {/* Create a bus connection and connect to the bus */BusAttachment bus = new BusAttachment(Service.class.getName());bus.connect();/* Register the service */Service service = new Service();bus.registerBusObject(service, "/myobject");/* Request a well-known name */try {

    bus.RequestName("org.alljoyn.echo", REQUEST_NAME_NO_FLAGS);} catch (BusException ex) {return;}/* Echo until told to stop */while (!stop) { Thread.currentThread().sleep(10000); }

    }/* Implementation of the echo method */public String Echo(String inStr) {

    return inStr;} }


    * Code snippets licensed under the Apache License, version 2.0

  • The Echo Client*public class Client {

    public static void main(String[] args) {

    /* Create a bus connection and connect to the bus */BusAttachment bus = new BusAttachment(Client.class.getName());bus.connect();/* Get a remote object */Class[] ifaces = { EchoInterface.class };ProxyBusObject proxyObj = bus.getProxyBusObject("org.alljoyn.echo", "/myobject", ifaces);EchoInterface proxy = proxyObj.getInterface(EchoInterface.class);

    /* Call the ping method on the remote object */try {

    String ret = proxy.Echo("Hello World");System.out.println(Echo returned: " + ret);

    } catch (BusException ex) {return;




    * Code snippets licensed under the Apache License, version 2.0

  • Summary


    OS and platform independent

    Multiple language bindings

    Multiple transports

    OS and platform independent

    Multiple language bindings

    Multiple transports

    Easier P2P Development

    Launched January 2011

    SDK download and forums at

    Sourced code available on GitHub at

    Launched January 2011

    SDK download and forums at

    Sourced code available on GitHub at

    Open Source Sponsored by QulC

    Download SDK Download Source Code Contribute

  • Questions?


  • Nothing in these materials is an offer to sell any of the components or devices referenced herein. Certain components for use inthe U.S. are available only through licensed suppliers. Some components are not available for use in the U.S.



    QUALCOMM Innovation Center, Incorporated5775 Morehouse Drive

    San Diego, CA. 92121-1714U.S.A.

    Copyright 2011 Qualcomm Innovation Center, Incorporated.

    All rights reserved.

    Not to be used, copied, reproduced in whole or in part, nor its contents revealed in any manner to others without the expresswritten permission of Qualcomm.

    Qualcomm and Uplinq are trademarks of Qualcomm Incorporated, registered in the United States.

    ALLJOYN is a trademark of Qualcomm Innovation Center, Inc.

    Other product and brand names may be trademarks or registered trademarks of their respective owners.