ASAP Session

ASAP Peers require a point-to-point connection to run an ASAP session. ASAP is a layer 3 protocol. The point-to-point connection must be provided from outside the framework. The project ASAPAndroid deals with this task on Android.

An ASAP Encounter is created by handing over two stream to an ASAP Peer.

InputStream is = // from somewhere else;
OutputStream os = // from somewhere else;
asapPeer.handleConnection(is, os);

The generic algorithm of an ASAP Session is easy. Details and variants are discussed later. Read run method of ASAPPersistentConnection if your are interested in the implementation.

1. Each ASAP Engine is asked to increase its era.
2. Each engine engine sends its format with ASAP interest message.
3. A reader thread is started.
4. The reader thread terminates after it received an ASAP prototol data unit (PDU). An executer thread is launched for processing. It tries to find an ASAP Enginer that supports the received format. Nothing happens if no such engine can be found. Otherwise, the engine takes over an processes the PDU, see details later. Execution thread is finished when the engine has finished its processing.
5. Step 3 is re-entered. Another read thread is created.

Applications can produce message during an ASAP Encounter. Such messages can be transmitted over this open connection. As synchronization is made to ensure that only one thread uses the output stream.

Both, reader and execution thread are observered. The thread is terminated if a maximal time interval is reached. This interval can be set. An ASAP session is terminated if the point-to-point connection is terminated. ASAP does not terminate any connection by its own.

Processing ASAP Interest

An ASAP Peer asks its engines to produce an interest PDU after recognizing a new ASAP encounter. That PDU contains the format string. The receiving peer tries to find an engine on its side which supports this format. The PDU is simple ignored if no such engien exists. The engine processes that PDU.

Implementation can be found in the handleASAPInterest method of class ASAPEngine. The algorithm is straightforward.

1. Check permission - if communication with remote peer is allowed or not (that's not fully implemented yet)
2. find era of last encounter with this peer - if no encounter happend before - the initial era is taken. Note: There are two relevant eras at this point. The current era was produced a few milliseconds ago when the new session was created, see first step above. We also know the era of the last encounter (or initial era, if never met before).
3. Engine sends any ASAP chunk within both eras which are meant to be received by the other peer. The other peer is receiver a) if no receiver was defined at all (open channel) or b) if it is on the receiver list (closed channel). Chunks are sent with the ASAP Assimilate PDU.

Processing ASAP Assimilate

Assimilate PDU are usually sent while processing an interest PDU.

Implementation can be found in the handleASAPAssimilate method of class ASAPEngine. The processing is extremly simple.

1. Each engine manages a storage for incomng messages for each peer. Received chunks are kept there.
2. The chunkReceived method is called if a listener was defined.

Implementing your own code - not supported yet.

This framework is not different to other protocol engines. There are methods to create PDUs. There are methods which implement algorithms which are called after a PDU was received. ASAP is a stateless protocol. The previous algorithm is one of many possible.

Nevertheless, there is not yet a way to inject your own code for PDU handling. Two reasons:

1. We figured that the implemented behaviour if sufficient to implement chats, a PKI and several other apps. It seems to be generic enough.
2. Implementing and testing such an API is a complex task. We know that because we did it. It took several person years and I have to confess: It was a mistake, see precessor of this lib: SharkFW. We put most of our efforts into a subproject that wasn't even necessary. After the re-launch we decided to make a slime framework first, implement apps which proof the concept and add any generic stuff later - if required (I doubt that very much.. after my learning curve with SharkFW.)

ASAP PDUs

[TODO] See ASAP PDU implementation

ASAP interest

[TODO] See ASAP Interest implementation

ASAP offer

[TODO] See ASAP Offer PDU implementation

ASAP assimilate

[TODO] See ASAP Assimilate PDU implementation