No differences.
Additions:
| ExtraInsertsSingleBlock |
Integer >= 0 |
Insert single blocks (not blocks above splitfiles, and not blocks in splitfiles) additional times. Testing has shown that a value of 2 (3 inserts total) can dramatically improve data persistence. We are still trying to figure out why. This defaults to 0 for single blocks because many FCP apps want to insert stuff quickly. |
ExtraInsertsSplitfileHeaderBlock |
Integer >=0 |
2 |
Insert blocks above splitfiles additional times. E.g. the CHK at the top of a splitfile, the CHK you actually fetch, is a single block. The splitfile itself has redundancy but the top block doesn't. So we insert it multiple times (3 by default) to improve the number of nodes it gets stored on. Tests show this dramatically improves data persistence, we are still trying to figure out why. |
No differences.
Additions:
| ForkOnCacheable |
Depends on node version |
Override insert behaviour: If true, fork an insert after its HTL becomes low enough for it to be cacheable. If false, don't fork the insert at this point. Inserts are not cached while their HTL is above 15, after that they can be cached, but this can be many hops because of probabilistic decrement, hence they may go over the "ideal" nodes or "sinks" where they should have been cached while they are still not allowed to, and the insert will not go back to those nodes because it's already been there. Forking deals with this by creating a new insert, which can go back over nodes we've already been to if necessary. |
Additions:
The node try to compress the data with the given codec, if more then one codec is given the node try to find the best in given order
The node tells the supported codecs in the NodeHello message
That setting has been introduced in 1231. |
Deletions:
The node try to compress the data with the given codec, if more then one codec is given the node try to find the best in given order
The node tells the supported codecs in the NodeHello message |
Additions:
DontCompress=false
Codecs=LZMA
Codecs |
a comma separated list of either names or ids |
The node try to compress the data with the given codec, if more then one codec is given the node try to find the best in given order
The node tells the supported codecs in the NodeHello message |
Deletions:
DontCompress=true
Additions:
| Data |
Binary data of specified length |
The data to insert. Muse be exactly DataLength bytes long. |
Additions:
Global=false
Whether the insert is visible on the global queue or not. If you set this as true, you should probably do a WatchGlobal, or you won't get any PutSuccessful / PutFailure message |
Deletions:
Global=true
Whether the insert is visible on the global queue or not. |
Additions:
Deletions:
| See EarlyEncode |
Additions:
| See EarlyEncode |
Deletions:
| Whether to aggressively encode the file's data in order to produce a key earlier (way before it would be fetchable; not generally recommended but useful for testing). |
Edited on
2007-07-14 19:26:27 by NextGens
[#1535: Remove all references to KSK@gpl.txt on the website]
Additions:
| This is an existing freenet URI such as KSK@sample.txt. The idea is that you insert a new key that redirects to this one. |
Deletions:
| This is an existing freenet URI such as KSK@gpl.txt. The idea is that you insert a new key that redirects to this one. |
Additions:
| If true, insert a binary blob (a collection of keys used in the downloading of a specific key or site). Implies no metadata, no URI. |
Deletions:
| If true, insert a [[BinaryBlobs binary blob]] (a collection of keys used in the downloading of a specific key or site). Implies no metadata, no URI. |
Additions:
BinaryBlob=false
BinaryBlob |
If true, insert a [[BinaryBlobs binary blob]] (a collection of keys used in the downloading of a specific key or site). Implies no metadata, no URI. |
Additions:
| This field will allow you to override any TestDDA restriction if you provide a hash of the content which should be inserted. It should be computed like that : Base64Encode(SHA256( NodeHello.identifier + '-' + Identifier + '-' + content)). That setting has been introduced in 1027. |
Deletions:
| This field will allow you to override any TestDDA restriction if you provide a hash of the content which should be inserted. It should be computed like that : Base64Encode(SHA256( NodeHello.identifier + '-' + ClientToken + '-' + content)). That setting has been introduced in 1027. |
Additions:
| This field will allow you to override any TestDDA restriction if you provide a hash of the content which should be inserted. It should be computed like that : Base64Encode(SHA256( NodeHello.identifier + '-' + ClientToken + '-' + content)). That setting has been introduced in 1027. |
Deletions:
| This field will allow you to override any TestDDA restriction if you provide a hash of the content which should be inserted. It should be computed like that : Base64Encode(SHA256( NodeHello.identifier + ClientToken + content)). That setting has been introduced in 1027. |
Additions:
FileHash=Base64String
FileHash |
a Base64 encoded SHA256 hash of the content you want the node to insert (only useful if you use UploadFrom=disk) |
This field will allow you to override any TestDDA restriction if you provide a hash of the content which should be inserted. It should be computed like that : Base64Encode(SHA256( NodeHello.identifier + ClientToken + content)). That setting has been introduced in 1027. |
Additions:
| Whether the FCP message includes the actual data, just the disk filename and path, or a redirection to an existing freenet key. If you upload from disk, you have to do a TestDDARequest. |
Deletions:
| Whether the FCP message includes the actual data, just the disk filename and path, or a redirection to an existing freenet key. If you upload from disk, you have to do a [[FCP2p0TestDDARequest TestDDARequest ]]. |
Additions:
| Whether the FCP message includes the actual data, just the disk filename and path, or a redirection to an existing freenet key. If you upload from disk, you have to do a [[FCP2p0TestDDARequest TestDDARequest ]]. |
Deletions:
| Whether the FCP message includes the actual data, just the disk filename and path, or a redirection to an existing freenet key |
Additions:
| Indicates the end of the message. If UploadFrom is direct, then the data follows this line. (Immediately after the newline). |
Deletions:
| Indicates the end of the message. If Upload''''From is direct, then the data follows this line. (Immediately after the newline). |
