Opened at 2007-05-04T05:22:57Z
Closed at 2008-02-13T01:42:18Z
#32 closed enhancement (fixed)
peer info in user interface
Reported by: | zooko | Owned by: | warner |
---|---|---|---|
Priority: | minor | Milestone: | 1.1.0 |
Component: | code-frontend-web | Version: | 0.7.0 |
Keywords: | web | Cc: | |
Launchpad Bug: |
Description
It would be cool if peer info such as IP address, how long I've been connected to them, or any other such information that is available could be displayed in the UI.
Change History (12)
comment:1 Changed at 2007-05-08T02:27:45Z by warner
- Owner changed from zooko to warner
- Status changed from new to assigned
comment:2 Changed at 2007-07-01T03:26:41Z by zooko
I was just showing Sam Stoller how Tahoe works, and I uploaded a file, and there was only one node on the network (my node, on my local demo network), so I wasn't actually achieving any "backup" functionality, but the user interface made it appear as though I was.
So if the information about which peers it is uploading to (successfully) should be displayed as part of the upload UI.
comment:3 Changed at 2007-07-25T03:35:55Z by warner
- Keywords web added
- Version set to 0.4.0
I've created #92 to cover that second goal: after upload, display which peers were used and how many shares went to whom.
I'll leave this one (#32) for enhancing the welcome.xhtml page to show per-peer information like how long you've been connected to them, a name they might publish ("Bob's Laptop"), maybe stuff about what kind of reliability your node assigns to them.
Of course, this information could also be shown on the #92 post-POST page, for the peers that were used, but #32 is for the data shown that's completely outside the scope of an upload operation.
comment:4 Changed at 2007-08-09T20:14:29Z by warner
#96 is related: there are many use cases where you really don't want to upload anything to yourself, and in these there should be a switch to turn such uploads off before they happen, rather than simply informing you about it after the fact.
comment:5 Changed at 2007-08-14T18:55:59Z by warner
- Component changed from code to code-frontend-web
comment:6 Changed at 2007-09-25T04:26:30Z by zooko
- Milestone set to 0.7.0
- Version changed from 0.4.0 to 0.6.0
I think of this as part of the "introduction/resource management/friendnet/deletion/etc." task. Assigning to Milestone 0.7.0.
comment:7 Changed at 2007-11-01T18:15:07Z by zooko
- Milestone changed from 0.7.0 to 0.7.1
- Version changed from 0.6.0 to 0.6.1
We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.
comment:8 Changed at 2007-11-13T18:27:13Z by zooko
- Milestone changed from 0.7.1 to 0.7.2
- Version changed from 0.6.1 to 0.7.0
We need to choose a manageable subset of desired improvements for [ http://allmydata.org/trac/tahoe/milestone/0.7.1 v0.7.1], scheduled for two week hence, so I'm bumping this one into v0.7.2, scheduled for mid-December.
comment:9 Changed at 2008-01-23T04:19:15Z by zooko
- Milestone changed from 0.7.2 to undecided
comment:10 Changed at 2008-01-26T00:27:01Z by zooko
Merging in #286 -- "display IP address of peers in Welcome page, other info like nickname too?"
comment:11 Changed at 2008-01-26T00:27:33Z by zooko
- Milestone changed from undecided to 0.10.0
comment:12 Changed at 2008-02-13T01:42:18Z by warner
- Resolution set to fixed
- Status changed from assigned to closed
It would be nice if the list-of-all-peers that you see on the web frontend could include two timestamps: one indicating how long that peer has been attached, and a second that indicates how long it has been since we've heard from that peer. The former should be recorded in and obtained from the IntroducerClient? class. The latter should be extracted from Foolscap-0.1.3's dataLastReceivedAt attribute (but foolscap should provide a clean accessor for it).
The central introducer node should have a small web ui where it can display the same information. The foolscap-vs-NAT issues that ought to be addressed by the keepalives introduced in foolscap-0.1.3 would be easier to examine and verify if we had such timestamps visible.