User:Rfc1394/Blame Transfer Protocol
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.
Specification
[edit]The BTP is based upon the following clasical scenario of blame transfer involving Alice and Bob, 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 blameholder has been found, the information is relayed back along the chain of peer questions. In this way, the blameholder's ID is received by the initiator of the query.
Message types
[edit]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.
WAS message
[edit]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.
Error handling
[edit]Mistaken identity
[edit]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.
Port assignment
[edit]The port used is unimportant, because typically when a round of blame is being transferred, nothing else is getting done anyway.
External links
[edit]- Quote #8102- In this example, a superuser exercises an option to take a more drastic action in response to a WAS message.