-
Notifications
You must be signed in to change notification settings - Fork 5
Packet JSONs
All communication between Master and Backbones happens in JSON. This is what it looks like. (All values apart from the type
field are dummy values)
The TransactionID
is set by the Master only.
If you run into inconsistencies between implementation and documentation his is because we failed to update the documentation properly. (This shouldn't happen, but who knows)
JSONs sent from Backbones to the Master for logging purposes.
{
"type": "A",
"transactionID": 0,
"sourceIP": "",
"destinationIP": "",
"finalDestinationIP": "",
"ceil": 0,
"deadline": 0,
"fine": 0,
"initialBudget": 0
}
{
"type": "B",
"transactionID": 0,
"sourceIP": "",
"destinationIP": "",
"bid": 0
}
{
"type": "W",
"transactionID": 0,
"sourceIP": "",
"destinationIP": "",
"winnerIP": "",
"winningBid": 0,
"fine": 0
}
Since Checks are never sent to the Master (and received from tha Master in bulk, see below), we don't need Check JSONs.
{
"type": "D",
"transactionID": 0,
"sourceIP": "",
"destinationIP": "",
"hopCount": 0,
"data": "";
"fine": 0
}
JSONs sent from Master to specific Backbones to trigger an action.
{
"type": "X",
"transactionID": 0,
"finalDestinationIP": "",
"hopCount": 0,
"dataLength": 0,
"data": "",
"fine": 0,
"ceil": 0
}
Sent periodically. The master will send Check data (i.e. Information about current balance & latest gains/losses) concerning all Clients to all Backbones. Each individual Backbone then picks out the data about the Clients that are currently connected to them.
{
"type": "U",
"devices": {
"172.18.18.156": {
"device": "172.18.18.156",
"balance": 15,
"balanceUpdates": [
{
"transactionID": 1,
"amount": 25
},
{
"transactionID": 2,
"amount": -10
}
]
},
"192.168.1.151": {
"device": "192.168.1.151",
"balance": -2,
"balanceUpdates": [
{
"transactionID": 2,
"amount": -5
},
{
"transactionID": 3,
"amount": 3
}
]
},
"192.168.1.152": {
"device": "192.168.1.152",
"balance": -2,
"balanceUpdates": [
{
"transactionID": 2,
"amount": -5
},
{
"transactionID": 3,
"amount": 3
},
{
"transactionID": 83,
"amount": 9
}
]
}
}
}
Idee dahinter ist, dass global ein Graph aufgebaut wird, der den Gewinn im Netz anzeigt. Gestartet wird bei 0 und nach jeder erfolgreichen Zustellung wird ein Gain zurückgegeben. Bei Verlust des Pakets wird angenommen, dass kein Gewinn/Verlust stattfindet. Realistisch? (Oder doch besser ins Minus gehen lassen, dadurch das Paket gedropt wurde und danach virtuell über den Backbone geroutet wird)
Folgende JSONs erstellt der Master (bzw. MongoDB auf Uhu) aus den gesammelten Daten: Collection "transactions":
{
"transactionID": 1,
"completed": true,
"successful": true,
"history": [
{
"device": "127.0.0.1",
"hop": 0,
"bid": 100,
"fine": 20,
"time": "blah"
},
{
"device": "127.0.0.2",
"hop": 1,
"bid": 90,
"fine": 19,
"time": "now"
},
{
"device": "127.0.0.4",
"hop": 3,
"bid": 20,
"fine": 5,
"time": "later"
}
]
}
Collection "balances" (Beispiel):
{
"type": "C",
"devices": {
"127.0.0.1": {
"device": "127.0.0.1",
"balance": 15,
"balanceUpdates": [
{
"transactionID": 1,
"sourceIP": "123.123.18.12",
"finalDestinationIP": "123.123.18.13",
"amount": 25
},
{
"transactionID": 2,
"sourceIP": "123.123.18.11",
"finalDestinationIP": "123.123.18.16",
"amount": -10
}
]
},
"123.123.123.2": {
"device": "123.123.123.2",
"balance": -2,
"balanceUpdates": [
{
"transactionID": 2,
"sourceIP": "123.123.18.11",
"finalDestinationIP": "123.123.18.16",
"amount": -5
},
{
"transactionID": 3,
"sourceIP": "123.123.18.18",
"finalDestinationIP": "123.123.18.19",
"amount": 3
}
]
}
}
}
All "time" values are conform to RFC 3339 + Nano "2006-01-02T15:04:05.999999999Z07:00".