User:Rfc1394/Blame Transfer Protocol
From Wikipedia, the free encyclopedia
The Blame Transfer Protocol or BTP is a transport layer protocol used to transfer blame. It is similar to TCP in its guarantees of data transmission and packet ordering, but instead of being a connection-oriented stream-based protocol, it employs the connectionless datagram model, such as that employed by UDP.
Contents |
[edit] Specification
The BTP is based upon the following scenario of blame transfer, which serves to exemplify the mechanism:
<X> Who stole the cookies from the cookie jar? <Alice> Bob stole the cookies from the cookie jar! <Bob> Who me? <Alice> Yes you. <Bob> Couldn't be. <Alice> Then who? <Bob> Y stole the cookies from the cookie jar!
Note that the blame is initially undetermined, and is then laid upon Bob by Alice. Bob denies it and transfers the blame to Y. Bob's role is taken by Y and Bob takes Alice's role. The process then repeats until the accused accepts responsibility. Since this may never occur, often an iteration number is passed along with every packet. Packets with iteration numbers above some arbitrary threshold are simply dropped.
Once the culprit has been found, the information is relayed back along the chain of peer questions. In this way, the culprit's name is received by the initiator of the entire inquiry.
[edit] Message Types
There are two types of messages in BTP, questions (WHO, ME) and answers (WAS, YES, NO). In BTP shorthand, the dialogue cited above becomes:
X to A : WHO ? A to * : WAS(B) ! B to A : ME ? A to B : YES ! B to A : NO ! A to B : WHO ? B to * : WAS(Y) !
(the asterisk represents a broadcast)
Internally, each peer has a stack of incoming and outgoing questions. When a question has been replied to, the peer pops it from the stack.
[edit] WAS Message
Implementations of the mechanism for choosing the argument for the construction of a WAS packet vary widely - from random selection to process-of-elimination algorithms involving trust and the propagation of information over a network of peers.
[edit] Error Handling
[edit] Mistaken Identity
Consider the following situation:
A to * : WAS(B) C to A : ME A to C : NO
Here the peer named C believes itself to be the peer B. A determines that C is in fact not B (through any method, such as checking C's IP or connecting to C's Ident port as IRC does) and responds with a NO packet. At this point, C should cease its current communications with A. It should respond to any further WAS packets, even if they are from A.
[edit] Port Assignment
The port used is unimportant, because typically when a round of blame is being transferred, nothing else is getting done anyway.
[edit] Additional Examples
- http://www.bash.org/?8102 - In this example, a superuser chooses to take a more drastic action in response to a WAS message.