This is a 2nd homework for a University course on Concurrent and Distributed Systems.
Each node holds a certain amount of bitcakes and engage in transactions that change their internal state. CLI Commands:
info
– Print this node's ID and neighbors.pause <ms>
– Pause execution for given milliseconds.transaction_burst
– Spawn 5 threads, each sending 5 random transactions (1–5 bitcakes) to other nodes.stop
– Gracefully stop the node.bitcake_info
– Initiates the global snapshot.
Algorithms:
- Coordinated Checkpoint – Custom algorithm
- Acharya-Badrinath – Lazy evaluation using vector clocks.
- Alagar-Venkatesan – On-demand snapshot with control messages.
Coordinated Checkpoint | Acharya-Badrinath | Alagar-Venkatesan | |
---|---|---|---|
FIFO system | Yes | No | No |
Snapshot included | Amount of bitcakes | Amount of bitcakes + channels state | Amount of bitcakes + channels state |
Who prints the snapshot | Every node | Node initiator | Every node |
Each node keeps:
- Number of bitcakes
Message Types:
TRANSACTION
: number of bitcakesSNAPSHOT_REQ
: node id of initiatorACK
: state of nodeRESUME
: empty message
Initiator's Perspective
- Sends a
SNAPSHOT_REQ
message and records its state - Waits for
ACK
messages from all other nodes. White waiting:- Receiving: puts incoming messages in a buffer
- Sending: pauses sending
- Sends a
RESUME
message to everyone - Prints all the states
Non-initiator's Perspective
- Upon receiving a
SNAPSHOT_REQ
message:- Sends an
ACK
message to the initiator with its state - Forwards the snapshot request to all neighbours
- Sends an
- Waits for the
RESUME
message from the initiator. While waiting- Receiving: buffers all incoming messages
- Sending: pauses sending
Each node keeps:
- Number of bitcakes
- Its vector clock
sentHistory
= list of <transaction_message>recdHistory
= list of <transaction_message>
Message Types:
TRANSACTION
: number of bitcakes, sender’s vector clockSNAPSHOT_REQ
: sender’s vector clockSNAPSHOT_REPLY
: nodeId, number of bitcakes, sent, recd
Initiator's Perspective
- The
bitcake_info
command is called - It sends a
SNAPSHOT_REQ
message with its vector clockV
(via causal broadcast) - Records its local state (bitcakes, sent/recd history)
- Waits for
SNAPSHOT_REPLY
messages from all other nodes. During this:- Receiving: records incoming messages where timestamp ≤
V
- Sending: pauses further message sending
- Receiving: records incoming messages where timestamp ≤
- Once all replies are received, it calculates the channel states:
ChannelState(pj→pi) = (number of bitcakes SENTj[i]) - (number of bitcakes RECDi[j])
- Prints the snapshot
Non-initiator's Perspective
- Receives
SNAPSHOT_REQ
message - Sends
SNAPSHOT_REPLY
message with its local state (bitcakes, sent and recd history)
Each node keeps:
- Number of bitcakes
- Its vector clock
Message Types:
TRANSACTION
: number of bitcakes, sender’s vector clockSNAPSHOT_REQ
: sender’s vector clockDONE
: emptyTERMINATE
: empty
Initiator's Perspective
- The
bitcake_info
command is called - Sends a
SNAPSHOT_REQ
message with its vector clockV
(via causal broadcast) - Records its own state (bitcake count)
- Wait for
DONE
messages from all. While waiting:- Receiving: records incoming messages where timestamp ≤
V
- Sending: continues as normal
- Receiving: records incoming messages where timestamp ≤
- Sends
TERMINATE
message (broadcast) - Prints its state and received messages between
DONE
andTERMINATE
Non-initiator's Perspective
- Upon receiving
SNAPSHOT_REQ
:- Records its own state (bitcake count)
- Sends a
DONE
(empty) message to the initiator
- Wait for the
TERMINATE
message. White waiting:- Receiving: records incoming messages where timestamp ≤
V
- Sending: continues as normal
- Receiving: records incoming messages where timestamp ≤
- Prints its state and received messages between
DONE
andTERMINATE