At present FCPv2 provides absolutely no status reporting. You fire a request, and either it succeeds or it fails. The client/async branch provides slightly more feedback (this will be merged soon):
ClientPut URI=<uri> Identifier=<ident> DataLength=<len> Verbosity=0 Data <data> GeneratedURI URI=<generated URI for the insert> Identifier=<ident> End PutSuccessful Identifier=<ident> URI=<same URI; should it be removed???> EndMessage The plan was always to provide as much feedback as the client required. So here's my suggested specification for that feedback: Verbosity is a bit-mask. Verbosity = 0 - see above, no feedback Verbosity & 1 == 1 => basic progress-bar info: SummaryProgress Identifier=<ident> Total=6572 // number of blocks expected to be inserted/retrieved Succeeded=322 // number of blocks actually completed so far TotalFinalized=true // total will not rise in future End Verbosity & 2 == 2 (and above) => include retry levels for some idea of how likely it is that this request will succeed SummaryProgress Identifier=<ident> Total=6572 Succeeded=322 TotalFinalized=true RetryLevel.0=0 // no blocks haven't been tried RetryLevel.1=0 // no blocks haven't been tried twice RetryLevel.2=5431 // most blocks have been tried 3 times! ... End Verbosity & 4 == 4 (and 1) => include error codes SummaryProgress Identifier=<ident> Total=6572 Succeeded=322 TotalFinalize=true Errors.13.Count=16384 // 16384 attempts got error code 13 Errors.13.CodeDescription=Data not found // code 13 = DNF Errors.14.Count=4098 // 4098 attempts got error code 14 Errors.14.CodeDescription=Route not found - could not find enough nodes to be sure the data doesn't exist ... End Verbosity & 8 == 8 => don't include CodeDescriptions, assume the client knows them Verbosity & 16 == 16 => include completion notifications about individual blocks BlockCompletedFailure Identifier=<ident> Number=32 // block number 32; this block's unique number RetryCount=5 // this block has been tried 5 times, including this time [ URI=<block uri> ] Code=16 [ CodeDescription ] [ ExtraDescription ] End Verbosity & 32 == 32 => include block start notifications BlockRequestStarted Identifier=<ident> Number=32 RetryCount=4 // block has been tried 4 times, not including this try [ URI=<block URI> ] End Verbosity & 64 == 64 => include URIs on completion notifications Verbosity & 128 == 128 => include URIs on start notifications Verbosity & 256 == 256 => include detailed info on structure of request FeedbackSimpleFetch Identifier=<ident> Target=<uri> End FeedbackSplitfileFetch Identifier=<ident> Type=<splitfile type> SegmentDataSize=<blocks per segment> SegmentCheckSize=<check blocks per segment> Size=<data size> CompressionAlgo=<compression algo type> DecompressedSize=<size after decompression> End etc. (all start with Feedback) Anything else that would be really useful to client authors? Anything in the above that is pointless or dangerous? Obviously the most important thing is verbosity = 1. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060125/140feb8c/attachment.pgp>
