BarterCast3: test with Libswift byte counting

[synctext]

Goal: Test-only of Libswift byte counting.
Aim: prepare for larger goal of "rewarding good behavior" #5.
Methodology: idea is to use agile 2-weeks releases with new features and test them in the wild, after DAS4 success.

Statistics from Libswift are used on both GUI and
the BarterCast3 community (the Tribler trust overlay).

Current situation:
sesscb_states_callback is called every second and retrieves the peer information of all swarms from libswift when wantpeers is True. Wantpeers is set to True when an BarterCast3 community exists or a detailspanel is selected in the librarylist.

Desired situation:
Only every 60 seconds BarterCast3 sets wantpeers to True and retreives the peer information of all swarms. Every 1 second, the GUI gets the peer information from one specific swarm if a detailspanel is selected.
New event notifier: libswift connection closed + last counters for that connection

Future wish list:
-Public key inclusion, therefore no missing-identity messages problem. Alters the walker, only for this community.
-Simple churn test
-Edge traversal and teleport
-Top250 edges

[synctext]

Libswift has now a suitable stats reporting API.

Uses the close event, see https://svn.tribler.org/libswift/branches/tribler-6.1.x-closeevent

{all work and info by Arno}
Note, this is just the swift side of things. Command syntax on TCP command socket is:

SUBSCRIBE <swarmidhex|ALL> <eventtype> <onoff>\r\n

Only the following is implemented:

SUBSCRIBE ALL CHANNEL_CLOSE 1\r\n

(and 0 for off). Now when a channel is closed, an event is queued which is currently dequeued and sent over the TCP connection when the state updates of the swarms are sent, so every 1 second (or whatever you configure with -C on swift command line).
swift -> Tribler, whenever a connection is closed

CLOSE_EVENT ROOTHASH IP PORT RAWBYTESUP RAWBYTESDOWN COOKEDBYTESUP COOKEDBYTESDOWN

In other words, after the INFO lines you get line like this:

CLOSE_EVENT 086a2b6cab9d58ab417f4c8976f78644399372ba 127.0.0.1:7758 170 0 0 0\r\n

to be parsed in SwiftProcess.py and transported to Dispersy.

[synctext]

#known ToDo
We just ignore for a while the possibility that peers go offline before Dispersy sends a signature-request.
First we solve the more difficult problems, before we dive into fixing details with known solutions; right?

[synctext]

#known ToDo (clarification)
Libswift only reports statistics after all data transfer in a swarm is completed.
Then Dispersy will request a signature in the BarterCast community as proof-of-work.
However, if the Libswift peer went offline, it's impossible to create a proof-of-work for that partial completed work.

Future solution is incremental signatures. For instance, every 90 seconds or every 25 MByte a seeder demands a signature. If no proof-of-work is given, uploading will stop. First we need scalable dissemination and rewards for good behavior #5.

[boudewijn-tribler]

The basic ideas in this issue have been implemented and will be part of Tribler in the near future in a simplified form:

• Bartercast community
• records will be disseminated using full gossip
• records will be created using simple hill climbing, max ?5? per ?30? minute cycle
• records will be pruned using global time values, after ?10.000? global time has elapsed

This issue also introduces some 'future features'. These will be implemented on the DAS4 first by Dimitra. The result will be moved into Trtibler when it is ready.

As this issue has no clear 'now it is finished' I propose we close it.