-
Notifications
You must be signed in to change notification settings - Fork 6
Home
Most applications follow the client-server paradigm. That's amazing since we know since the 1960th that server are a single point of failure and a good place to start espionage. Internet protocol and TCP were invented and became basis of a world-wide decentralized information system. It is a sad irony that the World-Wide-Web made the Internet technology popular in the 1990th. WWW is a client-server system par excellence with all its drawbacks.
The well-known issues from the time of the cold war are back in another context and with other lables: Distributed Denial of Service attacs (DDoS), exploiting private information, blocking web-sites, blocking or spying on communication networks just to name a few. History repeats itself. Very sad.
It is an even sadder irony that a lot of users talk about Internet applications but actually mean client-server-based WWW apps on a mobile phone or their laptops and are the opposite of the decentralized nature of IP.
Decentralized systems are still a good alternative. Internet was and is a brillant idea. Survailance capitalism would not work with decentralized apps. Decentralization is requirement for Internet of Things apps which collect a vast amount of information.
People do not have access to Internet anytime any anywhere. Local IT infrastructure can broken, overloaded, can be to expensive, to risky to be used (spying), no company could envision enough revenue for their shareholders to set up an appropriate infrastructure etc. pp.
ASAP general idea (eng.) / (ger).
Let's think apps decentralized. There are just a view apps which really require a server. Social networks do not - that's for sure. For what reason do we need a log of our very private conversations on a server somewhere in the world? To exchange messages? Really? Internet (IP) is decentralized. The infrastructure is out there - up and running for the better part of a century.
We (IT folks) should start thinking about decentralized systems instead working on pattern recognization stuff that squeezes out the last piece of information from communications which are meant to be private and which should be handled like this. We should think about systems which really work anywhere and not only in an area with perfect (wireless) Internet availability. We should think of systems which do not have to consider any law regarding privacy because they do not collect those data in the first place.
We should write real Internet apps - decentralized. Users and not only a few experts should be crystal clear where their data are and over what networks they are transmitted. Transparency can and should be the goal of the 21st century.
That is what ASAP is for: A protocol and programmers framework that allows building decentralized systems using Internet but also ad-hoc networks.
There is a little movie that explains in 10 minutes the core concepts on a basic example.
This library comes with a rudimentary user interface which can be used to "play" with asap. It can also be used to implement JUnit-Tests. That's a call for help. If you find bugs - please issue bug descriptions with a scenario description. It would help a lot. Thank you very much.
ASAP based apps are considered to be self-contained. Data, application and communication logic is within the application. ASAP apps are not meant to be complex apps. We implemented a messenger app, a public key infrastructure, a smart contract app but have no plans to implement system like weather predication. Rule of thumb: ASAP is good for
- small data sets
- apps which gather data in a very distributed manner like IoT apps
- apps with (small but) sensitive data with demands for strong privacy
- robust apps which can or should run on Internet but also ad-hoc networks
- apps which want to avoid a server as single point of failure / point to be spied on.
- apps who like / need / require full control over their communication networks.
An ASAP app is also called an ASAP Peer. Quite often, an ASAP app / peer is owned / used / can be attached to a human user. It is good practice to name an ASAP peer after its owner if their is any.
Following code sniplet illustrates creation of an ASAP peer which stores its data in a file system.
public static final String PEERS_ROOT_FOLDER = "asapPeersRoot";
...
String name = "Alice";
ASAPChunkReceivedListener asapChunkReceivedListener = null; // explained later
String folderName = PEERS_ROOT_FOLDER + "/" + name;
ASAPPeer asapPeer = ASAPPeerFS.createASAPPeer(name, // peer name
folderName, // peer folder
asapChunkReceivedListener // come back to this one later
);See javadoc for more details.
Applications can comprise several sub apps. A messenger keeps contacts beside chats. Even chats (or however such a construct might be called) can have a different behaviour. Some might be open - anybody can send messages. Some might be closed - only a defined group of users can exchange messages.
Each ASAP Peer comprises an arbitrary number of ASAP Engines. An ASAP Engines offers methods
- to manage data within an ASAP Storage
- to define strategies for data exchange during an encounter with another ASAP Peer.
Following code illustrates creation of an ASAP Engine.
String format = "yourApp/yourDataFormat";
ASAPEngine asapEngine = asapPeer.createEngineByFormat(format);The format string makes engine unique within its peer. It is recommended (but not required) to follow the idea of MIME format.
An engine is only created once when using createEngineByFormat. Subsequent calls would produce same engine again.
See javadoc for more details.
ASAP Peers run on a hardware which is able to create a point-to-point connection. We think of Bluetooth, Wifi-direct. But even protocols from ISO layer above 2 can be used, e.g. IP, TCP, even SMTP.
ASAP has no requirement to those point-to-point protocols. They can have a low bandwith, high probability of communication breakdowns. ASAP does not assume that a communication can be re-established after breakdown. Protocols can even be switched, e.g. to hide communication patterns.
Basic ASAP routing is very simple:
- ASAP apps produce messages and store them with an ASAP Engine.
- ASAP Peers can be provided with a established point-to-point connection - called ASAP encounter
- Each engine can send messages during this encounter. Each engine will remember its communication partner.
In most cases, ASAP is used for a delayed transmission of messages. Apps produce messages and store it with an ASAP Engine. Engines transmit those messages as-soon-as-possible (asap). They keep track of transmission. Message exchange behaviour can be customized for each engine, see [TODO - extra chapter]
Storing a message is straightforward.
byte[] message = // up to you;
CharSequence messageURI = "yourApp://aString";
asapEngine.add(messageURI, message);Your app must produce messages as byte arrays. It is recommended to described a message with an URI but it can be null, though. A URI helps to separate messages from e.g. different chats within the same ASAP chat engine. A URI can be null, though.
One A in ASAP stands for asynchroneous. Message are received during an ASAP encounter which happens - from ASAP Peer perspective - randomly. ASAP Engines send message during an encounter and store received message locally. (This standard behaviour can be changed - see [TODO]).
ASAP apps are informed about received messages with a ASAPChunkReceivedListener, see javadoc. ASAP app developers should implement a class implementing this interfaces and make it available to the ASAP Peer during its creation or later with setASAPChunkReceivedListener. The ASAP Chunk concept is very simple but not discussed here, see [TODO - details about message exhange].
Just a single method must be implemented. Here is an example:
import net.sharksystem.asap.util.Helper;
...
void chunkReceived(String format, String sender, String uri, int era) {
...
ASAPMessages receivedMessages = Helper.getMessagesByChunkReceivedInfos(
format, sender, uri,
folderName, // see peer creation
era);
Iterator<byte[]> msgInter = receivedMessages.getMessages();Received message a managed by an ASAP Engine. Those messages can be retrieved and deleted. In this code, a Helper class is used to produce a set of (ASAPMessages)[http://sharksystem.net/asap/javadoc/net/sharksystem/asap/ASAPMessages.html]. It is up to the application how to deal with received messages.
A fully functional example illustrates message exchange between to peers.
This movie explains the example code.
This movies illustrates the routing features of ASAP with a little triangle scenario.