<<O>> Difference Topic FreenetClientProtocol (r1.9 - 25 Feb 2002 - DeltaFourOhSeven) |
Deleted: | |
< < |
Key deletionNewer builds of Fred include aClientDelete command. This command is the first to require the use of the node's administrative password and can be used both as a tool for transient inserters and for people concerned about the contents of their datstore.
While it may be used to spread censorship, the impact of the ClientDelete command has yet to be determined.
(Client -> Node) ClientDelete password=<admin. password> keys.0=freenet:<key 0> [keys.N=freenet:<key N> EndMessageOpon receipt of the command, the node sends back a Success or Failed message. ClientDelete returns Success whether or not the key was in the datastore, and returns Failed if the administrative password is not correct. |
<<O>> Difference Topic FreenetClientProtocol (r1.8 - 06 Feb 2002 - DeltaFourOhSeven) |
Added: | |
> > |
|
Added: | |
> > |
Key deletionNewer builds of Fred include aClientDelete command. This command is the first to require the use of the node's administrative password and can be used both as a tool for transient inserters and for people concerned about the contents of their datstore.
While it may be used to spread censorship, the impact of the ClientDelete command has yet to be determined.
(Client -> Node) ClientDelete password=<admin. password> keys.0=freenet:<key 0> [keys.N=freenet:<key N> EndMessageOpon receipt of the command, the node sends back a Success or Failed message. ClientDelete returns Success whether or not the key was in the datastore, and returns Failed if the administrative password is not correct. |
<<O>> Difference Topic FreenetClientProtocol (r1.7 - 14 Jan 2002 - ZaB) |
Changed: | |
< < | |
> > |
|
<<O>> Difference Topic FreenetClientProtocol (r1.6 - 14 Jan 2002 - DeltaFourOhSeven) |
Added: | |
> > |
No, I made a few corrections and decided to sign it with my name to, among other things, update the revision date. I apologize for removing your name, I was not attempting to "steal credit"; but by the same token, I don't know that it's a good idea to keep a full changelog here either.
-- DeltaFourOhSeven - 13 Jan 2002 |
<<O>> Difference Topic FreenetClientProtocol (r1.5 - 11 Jan 2002 - EricNorige) |
Changed: | |
< < | %META:TOPICPARENT{name="WebHome"}% |
> > | %META:TOPICPARENT{name="Pub.WebHome"}% |
Changed: | |
< < | The FreenetClientProtocol (FCP) is designed to abstract the basics of Freenet so that client developers do not have to track the main Freenet protocol. FCP should be the bare bones of Freenet - metadata handling is not included in FCP though an extension to FCP may come about at a later date to avoid writing metadata handling libraries in many languages. |
> > | The FreenetClientProtocol (FCP) is designed to abstract the basics of Freenet so that client developers do not have to track the main Freenet protocol. FCP should be the bare bones of Freenet - metadata handling is not included in FCP though an extension to FCP may come about at a later date to avoid writing metadata handling libraries in many languages. |
Changed: | |
< < |
If the client is inserting a CHK or SVK, the URI may be abbreviated as just CHK@ or SVK@ . In the former case, the node will calculate the CHK, and in the latter, the node will generate a new keypair. The node must get all of the trailing field before it can start the insert into Freenet. The node may reply with one of the following messages:
|
> > |
If the client is inserting a CHK, the URI may be abbreviated as just CHK@ . In this case, the node will calculate the CHK. The node must get all of the trailing field before it can start the insert into Freenet. The node may reply with one of the following messages:
|
Changed: | |
< < |
I (TravisBemann) originally transcribed this document from a converted to HTML version of an SGML document by Adam Langley which originally documented FCP, along with a few changes to document the introduction of the Pending message, and changing wording and formatting in some circumstances. Thus I will credit Adam Langley with the majority of the content in this. However, someome else (DeltaFourOhSeven) attempted to take credit for this by deleting my signature and date stamp and replacing it with his or her own (without making any other significant modifications or additions, and if he or she did he or she should have just put his or her signature and date stamp by his or her modifications). I personally regard this as a major breach of etiquette. To the best of my knowledge this person is not Adam Langley, so I am removing this person's signature and date stamp from its position and just leaving it below mine for the reader to read.
|
> > |
I (TravisBemann) originally transcribed this document from a converted to HTML version of an SGML document by Adam Langley which originally documented FCP, along with a few changes to document the introduction of the Pending message, and changing wording and formatting in some circumstances. Thus I will credit Adam Langley with the majority of the content in this. However, someome else (DeltaFourOhSeven) attempted to take credit for this by deleting my signature and date stamp and replacing it with his or her own (without making any other significant modifications or additions, and if he or she did he or she should have just put his or her signature and date stamp by his or her modifications). I personally regard this as a major breach of etiquette. To the best of my knowledge this person is not Adam Langley, so I am removing this person's signature and date stamp from its position and just leaving it below mine for the reader to read.
|
Changed: | |
< < | -- TravisBemann - 05 Jan 2002, 07 Jan 2002 |
> > | -- TravisBemann - 05 Jan 2002, 07 Jan 2002 |
Changed: | |
< < |
-- DeltaFourOhSeven - 06 Jan 2002 |
> > |
-- DeltaFourOhSeven - 06 Jan 2002 %META:TOPICMOVED{by="EricNorige" date="1010732119" from="Pub.FreenetClientProtocol" to="Main.FreenetClientProtocol"}% |
<<O>> Difference Topic FreenetClientProtocol (r1.4 - 08 Jan 2002 - TravisBemann) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > |
(Node -> Client) <nop> |
Added: | |
> > | |
Added: | |
> > | (Node -> Client) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > | (Client -> Node) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > | (Client -> Node) |
Added: | |
> > | (Node -> Client) |
Added: | |
> > |
PostscriptI (TravisBemann) originally transcribed this document from a converted to HTML version of an SGML document by Adam Langley which originally documented FCP, along with a few changes to document the introduction of thePending message, and changing wording and formatting in some circumstances. Thus I will credit Adam Langley with the majority of the content in this. However, someome else (DeltaFourOhSeven) attempted to take credit for this by deleting my signature and date stamp and replacing it with his or her own (without making any other significant modifications or additions, and if he or she did he or she should have just put his or her signature and date stamp by his or her modifications). I personally regard this as a major breach of etiquette. To the best of my knowledge this person is not Adam Langley, so I am removing this person's signature and date stamp from its position and just leaving it below mine for the reader to read.
-- TravisBemann - 05 Jan 2002, 07 Jan 2002
This person attempted to take credit for putting this on freenetproject.org, dishonestly: |
<<O>> Difference Topic FreenetClientProtocol (r1.3 - 06 Jan 2002 - DeltaFourOhSeven) |
Changed: | |
< < | By default FCP is port 8481. but any FCP client should just use this as a default, rather than as a fixed value (because at some time in the future this could change or some user could change Freenet on their own machine to use a different port). |
> > | By default FCP is port 8481, but any client that uses FCP should leave this configurable, because this may be changed in the node's configuration file or by some future FCP revision. |
Added: | |
> > |
URI= |
Changed: | |
< < | -- TravisBemann - 05 Jan 2002 |
> > |
-- DeltaFourOhSeven - 06 Jan 2002 |
<<O>> Difference Topic FreenetClientProtocol (r1.2 - 05 Jan 2002 - IanClarke) |
Added: | |
> > | |
Changed: | |
< < |
<nop> |
> > |
<<O>> Difference Topic FreenetClientProtocol (r1.1 - 05 Jan 2002 - TravisBemann) |
Added: | |
> > |
%META:TOPICINFO{author="TravisBemann" date="1010270940" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="WebHome"}%
AbstractThe FreenetClientProtocol (FCP) is designed to abstract the basics of Freenet so that client developers do not have to track the main Freenet protocol. FCP should be the bare bones of Freenet - metadata handling is not included in FCP though an extension to FCP may come about at a later date to avoid writing metadata handling libraries in many languages.NoteThis protocol is never meant to go across a network - only via the loopback. Nodes should not accept FCP connections from hosts other than localhost by default.BasicsBy default FCP is port 8481. but any FCP client should just use this as a default, rather than as a fixed value (because at some time in the future this could change or some user could change Freenet on their own machine to use a different port). FCP follows the FNP setup for session and presentation. In the following, numbers are always hex-encoded and fields in square-brackets are optional. FCP allows one transaction per connection, after which the connection is torn down. At the beginning of each connection, the client must send these 4 bytes:00 00 00 02
These are the 2-byte session identifier and the 2-byte presentation identifier. In the future, different identifiers may be used to allow alternate syntaxes or encrypted FCP connections from remote hosts, for example.
After sending the session and presentation identifiers, the client sends a message to initiate the transaction, then waits for one or more messages from the node until the transaction is complete. Messages are a series of lines terminated by LF or CRLF, in this form:
Header [Field1=Value1] . . [FieldN=ValueN] EndMessage Message summaryThis is the complete set of client to node messages, with the possible node to client responses (only the headers are listed).
FormatError , meaning the command was not understood, and the node may responsd at any time with a Failed , indicating a fault in the node itself:
FormatError [Reason=<descriptive string>] EndMessage Failed [Reason=<descriptive string>] EndMessage Failed and FormatError will not be discussed in the remainder of this document. Clients should be prepared to handle a Failed at any time, and a FormatError as teh response to any client message. Either of these messages terminates the transaction and the connection.
HandshakingThis is totally optional for the client. Note that this counts as a transation and thus the connection is torn down afterwards.(Client->Node) ClientHello EndMessageIn response the node sends the following message: (Node->Client) NodeHello Protocol=<number: protocol version number. Currently 1> Node=<string: freeform: Description of the nodes> EndMessage Requesting(Client->Node) ClientGet URI=<string: fully specified URI, such as freenet:KSK@gpl.txt> HopsToLive=<number: hops to live> EndMessageThe client is now in the waiting state. The node may return one of the following messages:
DataFound message is returned:
DataFound DataLength=<number: number of bytes of metadata + data> [MetadataLength=<number: default = 0, number of bytes of metadata> EndMessageAfter a DataFound message the data itself is sent in chunks:
DataChunk Length=<number: number of bytes in trailing field> Data <@Length bytes of data>At any time when the full payload of data has not been sent a Restarted message may be sent. This means that the data to verify and the transfer will be restarted. The client should return to the waiting state, and if a DataFound is then received, the data transfer will start over from the beginning. Otherwise, when the final DataChunk is received, the transaction is complete and the connection dies.
Inserting(Client->Node) ClientPut HopsToLive=<number: hops to live> URI=<string: fully specified URI, such as freenet:KSK@gpl.txt> DataLength=<number: number of bytes of metadata + data> [MetadataLength=<number: default = 0, number of bytes of metadata>] Data <@DataLength number of bytes>If the client is inserting a CHK or SVK, the URI may be abbreviated as just CHK@ or SVK@ . In the former case, the node will calculate the CHK, and in the latter, the node will generate a new keypair. The node must get all of the trailing field before it can start the insert into Freenet. The node may reply with one of the following messages:
Pending messages may be returned. These messages signal that the data is being successfully inserted, but insertion is not complete, and the node has not received a StoreData message yet:
Pending EndMessageWhen the node receives a StoreData message (and thus insertion is complete), a Success message is returned with the Freenet URI of the new document and possibly a private/public keypair, if the inserted document was an SVK. See the section on key generation about this.
Success URI=<string: fully specified URI, such as freenet:KSK@gpl.txt> [PublicKey=<string: public key>] [PrivateKey=<string: private key>] EndMessage Key generationThese messages allow a client to generate keys. This does not affect Freenet at all - the calculations are carried out at the node. Key generation requests are done via aGenerateKey message. Either a CHK or an SVK keypair can be generated:
GenerateCHK DataLength=<number: number of bytes of data + metadata> [MetadataLength=<nubmer: defaul = 0, number of bytes of metadata>] Data <@DataLength number of bytes> The node calculates the CHK as it would do if inserting, but instead returns it. This completes the transaction:Success URI=<string: fully specified URI, such as freenet:KSK@gpl.txt> EndMessageThe format for generating SVKs is very similar but generates a pair of keys (public and private) which are independent of any data. This is generally used for setting up SSKs:GenerateSVKPair EndMessageThe node generates a key pair and returns:Success PublicKey=<string: public Freenet key> PrivateKey=<string: private Freenet key> EndMessageThe |
Topic FreenetClientProtocol . { View | Diffs | r1.9 | > | r1.8 | > | r1.7 | More } |
Revision r1.1 - 05 Jan 2002 - 22:49 GMT - TravisBemann Revision r1.9 - 25 Feb 2002 - 03:42 GMT - DeltaFourOhSeven |
This website is distributed under the GNU Documentation License |