AirTube for Android (tkaiso)

  • What is AirTube

AirTube is an easy to use networking library for Android and Java creating a distributed peer-to-peer overlay mesh network with service discovery and asynchronous message-oriented end-to-end connectivity. By combining these three main features into a small and dedicated library, AirTube frees application developers from worrying about networking details like topologies, IP addresses and port numbers, and simply lets them discover "services" and receive data from it, be it local, remote or anywhere in the global AirTube overlay mesh "cloud".

Allthough AirTube is a generic networking library for Java, it is optimized for Android mobile devices and the transmission of real-time multimedia data like streaming audio and video.

AirTube is an Open Souce project and licensed under the LGPL.

  •  How AirTube works
    • AirTube Topology

AirTube creates a peer-to-peer network in a single lan, over local L3 network and also over Internet even without a servier device. To realize a peer to peer network over L3 network (including over Internet), AirTube provides overlay mesh network functionality on "OSI Layer 7". 

Next slide shows simple topology composed of a single LAN network. As descibeed before, AirTube can run not only on Android devices but also simple Java platform including a PC. Here in this document, AD stands for "AirTueb running on Android" and AJ stands for "AirTube running on Non-Android platform".  we call this latter case also "AirTube on Pure Java".  Case 3 in this slide shows the topology built on IEEE 802.11 IBSS network, which is standard functionality defined in 802.11, but most of the commercial Android devices fail to implement it. But we, thinktube, also worked for this ........ (not yet completed )  please refer http://www.thinktube.com/tech/android/wifi-ibss 

 Next slide shows the topology over local L3 network. One of the core AirTube technologies is "overly mesh network" which connect the AirTube network in a LAN and explore the best route to reach the AitrTube destination node. AirTube implements it's own flavor of the advanced distance-vector (DV)  combined with on-demand(OD) routing protocol invented by Thinktube. After detecting its neighbourhood in its L2 network, AirTube node distributes the information about the shortest paths to all participants of the network across multiple LAN segement. Each member of this multi-hop network will route data on behalf of other devices following the best path to the destination: Local data will be routed locally while at the same time global connectivity is possible.

I need to descibe "solution1" and "solution2".  in below, AG is wrong, I must replace it with AJ node = local relaying AT node (not need to have global IP address)

 

 Next slide shows the topology of AirTube Peer to peer network over Internet. To realise this, we need an AirTube relay node with a global IP address. we call this "AG" node in this slide. At least one AirTube node in a local network must have the global IP address of the AG node so that service information packets and user application data might be routed thrugh the AG node to reach remote AirTube network.

In addtion to Airtube Nodes in local networks, AirTube node connected over 3G/LTE network can also join this Airtube network by assiging the proxy(relay) node address explicitly. please see case1 below.  Case2 shows more advanced topology in which multiple AG nodes are conneted in Internet cloud. this configuration brings the benefits of more flexible administration and also redundancy increasing the reliability.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

following panel shows AirTube Monitor daemon screen on each Android device.

    • Airtube Monitor daemon panel on an Android device

      remote peer node list

          traceroute utility  

      Left panel: PEERS

      This peer has 6 remote  peers, 4 of them are Neighbours direclty connected to this peer and 88 is a 2 hop peer reached via 77. 15086 is a 3 hop peer reached via 77->88.   

      Left panel: TRACEROUTE

      This peer can reach peer 88 via 77

       

    • Service discovery

Every device in an AirTube network can announce one or more services which are identified by an "AirTubeID". AirTubeID is composed of "Device ID" and an integer value, which is dynamically assigned when the service is registered to the AirTube. This is equivalent to the combination of IP address and port as in layer 3 network.  In the following screen shot, 3/15086... is the AirTubeID for the "test" service.  

Clients interested in a certain service can search for a "service name" and will be notified of any service which is available with that name. In the screenshot, there exist five services which are represented as "video", "audio", "test" and "cv/people-count" respectively.  Service can further be described by a service-specific JSON string (e.g:  { "codec": "h264", "width": 640, "height": 480 }) and the service can choose a particular transmission type and its type of service (ToS/QoS). Services descriptions are spread thru the network. Services themselves don't need to manage clients' state, they just publish their data and AirTube takes care of distribution the data to all clients. All data transmission and service subscription is done efficiently and asynchronously and on a message (packet) basis using the Java NIO framework.

Left panel : SERVICES

SERVICES panes shows the lisy of available services in this AirTube network.

In this example, there are 5 services now on remote peers

  • video : AirTubeID[11/c04a..] provides this service, ToS is VIDEO
  • audio : AirTubeID[3/1508..] provides this service, ToS is VOICE
  • test   : AirTubeID[5/5e53..] provides this service, ToS is NORMAL
  • video : AirtubeID[2/5e53..] provides this service, ToS is VIDEO
  • cv/people-count : AirTubeID[1/5e53..] provides this service, ToS is NORMAL

 

As this example shows, single Android device can provide multiple services and there can be more than one service providers for the same sevice name.

"cv/people-count" services provides "computer vision" service which is counting the number of people by our developing CV algorithm and sends the result (people number) to the clients.  Each client has its own threhold to start subscribing the video service from this service peer. 

 

 

     

      • Publish/Subscribe

    Services in the AirTube network follow the "publish/subscribe" paradigm, and any participant in the network can announce "services" which are found by "name" (String) and are further described by service-specific JSON. Once a service has been found, clients can subscribe to the service in order to receive the service data (e.g. video stream) or to send data to the service.

    To make the data sending and receiving simple and efficient for its users, AirTube provides an asynchronous message-oriented networking abstraction. Services and clients can simply specify the type of data transmission they want (e.g. UDP, TCP or Broadcast) and then simply pass data packets to AirTube, which will transport them over the best path to the destination.

     

     

     

     

     

                   AirTube Network         Features              
     airtube-concept-2
    • Service Discovery
    • Piblish/Subscribe Messaging
    • Overlay Mesh Networking

     

    • Comparison to "Bonjour" or "DNS-SD"

    One of the most commonly used "service discovery" protocols is Apples "Bonjour" or more technically "DNS-SD" over multicast DNS. While it can be useful to find and announce services in a local network, and it can help assign local IP addresses automatically, it leaves many problems unsolved. Application developers still have to manage and assign port numbers to its services and then implement the whole IP socket communication themselves. A typical DNS-SD program has to:

    1) Assign IP addresses, possibly with the help of DNS-SD "Zeroconf"
    2) Assign a port number to the "service"
    3) Write a UDP or TCP server to listen on the service port
    4) Use DNS-SD to announce the "service" like "myService.tcp.local"
    5) Use DNS-SD to resolve the service "myService" to an IP address and port
    6) Open a UDP or TCP connection to that IP address and port
    7) Define the application protocol on that connection

    In comparison with AirTube you just have to:

    1) Register a service "name" with AirTube
    2) Look up the service "name" on the client and subscribe to it
    3) Define the application protocol on that "service"

    In AirTube that service can even change IP addresses, or move location, and still maintain the data connection to the client which subscribed before.

    • Download the code and other technical documents

    https://github.com/thinktube-kobe/airtube