-
Notifications
You must be signed in to change notification settings - Fork 1
Home
The Asynchronous Semantic Ad-hoc Protocol (ASAP) is address and content-based routing protocol for large scaled ad-hoc networks. OK, now in English:
Some apps want to deliver messages from phone to phone with an ad-hoc network, like Bluetooth. Some even want a hop-to-hop feature, like A sends something to B, B to C and so forth.
Classic ad-hoc network routing protocols (like DSDV, DSR) do not fit exactly. They look for an existing route from A to C at a specific moment. But what if B moves, has first a connection with A which get lost and finally connects with C. There would never be a route from A to C over B at one moment in time. We talk about time shifted ad-hoc networks. B could transmit the message anyway. But not with an ad-hoc network routing protocol.
Human society was always such an ad-hoc network. We meet, talk, meet others, talk again... Call it gossip. We call it routing in large scale time shifted ad-hoc networks.
The good old SMTP follows the store-and-forward concept to deliver e-mails from host to host. ASAP follows that idea. But it does not require Internet. It only requires point-to-point protocols, regardless of their reliability. UDP is fine. TCP is good as well. A secured channel via TOR is even better. Bluetooth works as well as Wifi Direct, LoRa etc. pp. ASAP has no requirements at all. Connection breakdown is considered normal. ASAP does not assume that a connection to another peer can be re-established. ASAP works like what asap also means: It delivers messages as soon as possible.
Each ASAP message can (no must) have a sender, recipient(s) and a uri. The later allows a semantic tagging which allows implementing content-based routing. Each peer can decide based on a topic whether to forward a message or not. You could implement a pure decentralized variant of something like Twitter with that feature. The ultimate echo chamber.
We use the term peer with ASAP due to the lack of a better name. ASAP is not basis of a Peer-to-Peer system, though. A P2P system is meant to optimize throughput of a network by an adaptive data allocation strategy. ASAP is much easier. An ASAP peer has got data. It can transmit and received data. That's it. Your app can make more of it.
Your messages could be chat messages, smart contracts, a certificate. Any distributed app that can work by exchanging messages between its parts is an ASAP app. ASAP mimics verbal communication in a very rudimentary way. Anything that can be done by verbal communication can be a blueprint of an ASAP application. We would not introduce an artifical server which does not exist in human verbal communication. We would implement it the same way we talk. It would be as secure as a private verbal conversation.
Before you begin, have a look at the ASAP wiki to learn the view core concepts. This repository is not the ASAP implementation. It runs an ASAPPeer as a service and offers methods to control it. Releases contain the ASAPJava library. Choose this library for an convinient way to build decentralized apps with Android which have a user interface. Choose ASAPJava to build a standalone project or an Android service.
Version 1 supports Bluetooth as layer 2 protocol. We work on others (Wifi, LoRa but also wide range networks, especially SMTP, TOR etc.).
An ASAPPeer is the central element. It stores, delivers and receives messages from other peers. An ASAPPeer runs as a service in this library. It runs in the background, establishes ad-hoc connection whenever possible and allowed. It launches ASAP sessions automatically.
You application has not to deal with any details of layer 2 protocols, like connection establishment, sending data etc. pp. Your application just sends and receives messages. ASAP makes the store and forwarding. Your application can control the behaviour of the ASAPService, though.
Android applications can send messages to services. Service use broadcast to notify activities. We use the same concept in the library and hide those details from you application.
The ASAPApplication is the application side proxy of the ASAPPeer running in the service. You must implement a singleton class that is a aubclass of ASAPApplication. Example code follows later.
ASAP messages are exchanged whenever peers encounter each other. Your app stores messages. The ASAPService performs that exchange and notifies ASAPApplication about received data. You implement a listener and subscribe with ASAPApplication.
Android activities play an important role in those scenarios. The manage to get information from users (e.g. a message in a chat) and show information on screen. Activities actually send and receive messages. ASAPActivity provides a number of useful methods. Activities who deal with message exchange must be a subclass of ASAPActivity. ASAPActivity will bind to and unbind from the ASAPService during onCreate() and onStop They register themselves as broadcast listener and so an. ASAPService (service site) and ASAPApplication (your app site) communication is hidden in this library and that is a good thing. It makes implementing much easier.
It is actually pretty simple to implement a Bluetooth based messenger with this library. The example code code consists of four classes which are not very complicated. The complex stuff is hidden in this library. As it should be.
Your first job is to design your application.
Most important: Your application is decentralized. You applications consists of independent parts - call them peers. Each can store its own data and can decide when (and where) it is willing to interact with others.
That own will has its limitations, though. A little sensor in an IoT application won't have a sophisticated rule set of access rights. But even such a device could have a black/white list or rules to whom it send what kind of data (complete data set, a summary, ..)
Anyway: Your app is made up of peers that exchange messages. That's your general pattern.
Peers and (human) users can and should be seen as a unit in a lot of application classes. It can be taken literally when it comes to smartphone apps. User can move and switch on and off their phones as they please.
Do not even think of introducing some kind of super-peer into your design. There cannot be peers, which are always reachable, always online, collects all or a lot the data. An entity that cannot do any work without another one is no peer.
Features of a peer are:
- Autonomy: It can move (or be moved - mobile phone). It can go on-/offline at any time.
- Data exchange is message exchange: Any communication comes down to asynchronous message exchange. Never assume a stable communication stream to any part in the system. Do not assume high bandwith.
- There is no central site if you write a pure decentralized system. There is no centralized database, that collects all the data or keeps track of exchanged data. There is no central archive. Decentralized systems are very good in forgetting. Single peers can have a good memory. But the whole system has non.
(My personal impression: We barely call apps WWW apps or even World Wide Web apps. But the vast majority of apps are. There are servers offering services with some variant of an HTTP API. That's ok. It is WWW. No shame. It is an architectural model that was considered vulnerable even in the 1960th. Who cares ;)
They are called Internet apps in common speech instead. Sounds cooler doesn't it. It is not earned, though. Internet is a decentralized network - most apps are not. You are going to implement an Internet app. The irony: If you stick to ad-hoc networks: You will not use Internet at all.)
You made a big step when you designed your application that way. It differs to the usual de# the beginnings of this century. It is more a real Internet application and less a WWW applications - it is decentralized.
The final steps are handcraft.
- Define you data structures.
- Define what happens if peers encounter. What do they exchange. How do they react on received messages.
- Most apps consists of sub-applications. A messenger usually consists of a message exchanger but also a part that exchanges personal information to manage the contact list. Separate different parts of your app. It becomes much easier.
Now, you are ready to implement. There is no advice for GUI design here. In terms of MVC: This lib helps to implement model and control. It makes any communication for you.
Now, have a look in ASAPApplication and ASAPActivity. Afterwards have a look in an example app
If you like, have a look in our more complex ASAP based messenger SharkNet2 (which is and probably will always be work in progress).
This movie shows how to set up Android Studio to become ready for a new ASAP. application.