| ... | @@ -31,7 +31,7 @@ Besides creating local wallets (i.e. wallets running in the same JVM as the supe |
... | @@ -31,7 +31,7 @@ Besides creating local wallets (i.e. wallets running in the same JVM as the supe |
|
|
*__Attention when using eduroam:__ The eduroam network does not allow communication between its network clients! If you want to test the remoting part over a network you will have to use your home network or create an ad-hoc network.*
|
|
*__Attention when using eduroam:__ The eduroam network does not allow communication between its network clients! If you want to test the remoting part over a network you will have to use your home network or create an ad-hoc network.*
|
|
|
|
|
|
|
|
## Joining
|
|
## Joining
|
|
|
The following section describes the process of a new wallet (no matter if local or remote):
|
|
The following section describes the process of the join of a new wallet (no matter if local or remote):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ... | @@ -44,7 +44,16 @@ The following section describes the process of a new wallet (no matter if local |
... | @@ -44,7 +44,16 @@ The following section describes the process of a new wallet (no matter if local |
|
|
|
|
|
|
|
## Distributed Commit
|
|
## Distributed Commit
|
|
|
|
|
|
|
|
[TODO]
|
|
The distributed commit is performed by a exchanging quite a lot messages between the sender, the supervisor and all wallets in the network. In the following figure the flow of messages is visualized with the colors standing for different stages of the distributed commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. The wallet wanting to send money to another wallet, starts the distributed commit by sending an `ActionInvokeSendMoney` to itself (this results in the sender executing the `onAction` method of the action). This is part of the first stage -- the initialization stage (marked with red in the figure). This message contains the basic information about the transfer, i.e. sender, recipient and the amount.
|
|
|
|
2. The sender then sends a `ActionInvokeDistributedCommitTransfer` message to the supervisor. It will then create a `DistributedCommittedTransferRequest` for its internal request queue and gives the transfer a unique id. After that it will send an `ActionPrepareDistributedCommittedTransfer` to __all__ of its neighbors (i.e. all nodes in the network) with all information about the transfer available at this point (the information above plus the id and a timestamp).
|
|
|
|
3. The `ActionPrepareDistributedCommittedTransfer` message is already part of the second stage (in the figure indicated with green) where every wallet has to agree to the commit. Upon receiving such a message, the wallet will look into its internal ledger to see whether the sender has enough money to perform the transaction. If the transfer fulfills all requirements, the wallet answers with an positive `ActionPrepareDistributedCommittedTransferAnswer` containing the id and the information whether the wallet grants the transfer. Otherwise it will answer with a negative message.
|
|
|
|
|
|
|
|
4. The supervisor receives all answers and counts the positive results of the request. When all wallets agree with the commit, the supervisor will grant the commit and will send a positive `ActionCommitDistributedCommittedTransfer` to all nodes. If a wallet disagree with the transfer, all wallets will receive the same message with a negative answer.
|
|
|
|
5. After a wallet received a positive `ActionCommitDistributedCommittedTransfer ` from the supervisor, it will update its internal ledger. The directly involved wallets will update their amounts. This is part of the last stage, the actual transfer and updating of the ledgers.
|
|
|
|
|
|
|
|
## Tasks, issues and open problems
|
|
## Tasks, issues and open problems
|
|
|
|
|
|
| ... | |
... | |
| ... | | ... | |
