diff --git a/i2p2www/pages/site/docs/api/bob.html b/i2p2www/pages/site/docs/api/bob.html index ef058796..f0cbf0bd 100644 --- a/i2p2www/pages/site/docs/api/bob.html +++ b/i2p2www/pages/site/docs/api/bob.html @@ -1,48 +1,77 @@ {% extends "global/layout.html" %} {% block title %}BOB{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block content %} -
-Technical differences from SAM (for the better?)
+
{% trans %}BOB - Basic Open Bridge{% endtrans %}

 
+
{% trans %}Technical differences from SAM (for the better?){% endtrans %}

 
+
{% trans -%}
 BOB has separate command and data channels. 
 One, an application command channel socket to router to configure.
 Two, the application data sockets to/from router that carry only data.
 The command channel is only needed for making or setting the initial
 destination key, and to set the destination key to port bindings. 
 All connections run in parallel.
+{%- endtrans %}

 
-SAM One connection that does everything, and you need to parse every packet.
+
{% trans -%}
+SAM has one connection that does everything, and you need to parse every packet.
+{%- endtrans %}

 
+
{% trans -%}
 BOB does not hold keypair values, nor does the router.
 Your application holds the keypair values. 
 This is to reduce any extra complexity in the router code, it also adds to
 your privacy.
+{%- endtrans %}

 
+
{% trans -%}
 SAM router stores every keypair you ever make.
+{%- endtrans %}

 
+
{% trans -%}
 Those are the important differences.
+{%- endtrans %}

 
-KEYS = keypair public+private, these are BASE64
-KEY = public key, also BASE64
+
{% trans -%}
+KEYS = keypair public+private, these are BASE64
+{%- endtrans %}

+
{% trans -%}
+KEY = public key, also BASE64
+{%- endtrans %}

+
{% trans -%}
+ERROR as is implied returns the message "ERROR "+DESCRIPTION+"\n", where the DESCRIPTION is what went wrong.
+{%- endtrans %}

+
{% trans -%}
+OK returns "OK", and if data is to be returned, it is on the same line. OK means the command is finished.
+{%- endtrans %}

+
{% trans -%}
+DATA lines contain information that you requested. There may be multiple DATA lines per request.
+{%- endtrans %}

 
-ERROR as is implied returns the message "ERROR "+DESCRIPTION+"\n", where the DESCRIPTION is what went wrong.
-OK returns "OK", and if data is to be returned, it is on the same line. OK means the command is finished.
-DATA lines contain information that you requested. There may be multiple DATA lines per request.
-
-NOTE: The help command is the ONLY command that has an exception to
+
{% trans -%}
+NOTE: The help command is the ONLY command that has an exception to
 the rules... it can actually return nothing! This is intentional, since
 help is a HUMAN and not an APPLICATION command.
+{%- endtrans %}

 
-PLEASE NOTE:
+
{% trans -%}
+PLEASE NOTE:
 For CURRENT details on the commands PLEASE use the built-in help command. 
 Just telnet to localhost 2827 and type help and you can get full documentation on each command. 
+{%- endtrans %}

 
+
{% trans -%}
 Commands never get obsoleted or changed, however new commands do get added from time to time.
+{%- endtrans %}

 
-Here are the commands we have as of this writing (Aug 2010).
+
{% trans -%}
+Here are the commands we have as of this writing:
+{%- endtrans %}

 
-COMMAND     OPERAND                             RETURNS
+
+{{ _('COMMAND') }}     {{ _('OPERAND') }}                             {{ _('RETURNS') }}
 help        (optional command to get help on)   NOTHING or OK and description of the command
 clear                                           ERROR or OK
 getdest                                         ERROR or OK and KEY
@@ -67,12 +96,16 @@ stop                                            ERROR or OK
 verify      KEY                                 ERROR or OK
 visit                                           OK, and dumps BOB's threads to the wrapper.log
 zap                                             nothing, quits BOB
+

 
+
{% trans -%}
 Once set up, all TCP sockets can and will block as needed, and there is no need for any 
 additional messages to/from the command channel. This allows the router to pace the
 stream without exploding with OOM like SAM does as it chokes on attempting to shove 
 many streams in or out one socket -- that can't scale when you have alot of connections!
+{%- endtrans %}

 
+
{% trans -%}
 What is also nice about this particular interface is that writing anything to interface 
 to it, is much much easier than SAM. There is no other processing to do after the set up.
 It's configuration is so simple, that very simple tools, such as nc (netcat) can be used 
@@ -82,39 +115,53 @@ to stop that application. Instead, you can literally "unplug" the destination, a
 "plug it in" again. As long as the same IP/port addresses and destination keys are used 
 when bringing the bridge up, the normal TCP application won't care, and won't notice.
 It will simply be fooled -- the destinations are not reachable, and that nothing is coming in.
+{%- endtrans %}

 
+
{% trans -%}
 For the following example, we'll setup a very simple local loopback connection, 
 with two destinations. Destination "mouth" will be the CHARGEN service from 
 the INET superserver daemon. Destination "ear" will be a local port that you
 can telnet into, and watch the pretty ASCII test puke forth.
+{%- endtrans %}

 
-EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works
-A = Application
-C = BOB's Command response.
+
+{% trans %}EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works{% endtrans %}
+A = {{ _('Application') }}
+C = {% trans %}BOB's Command response.{% endtrans %}
 
-FROM 	TO	DIALOGUE
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	setnick mouth
 C	A	OK Nickname set to mouth
 A	C	newkeys
 C	A	OK ZMPz1zinTdy3~zGD~f3g9aikZTipujEvvXOEyYfq4Su-mNKerqG710hFbkR6P-xkouVyNQsqWLI8c6ngnkSwGdUfM7hGccqBYDjIubTrlr~0g2-l0vM7Y8nSqtFrSdMw~pyufXZ0Ys3NqUSb8NuZXpiH2lCCkFG21QPRVfKBGwvvyDVU~hPVfBHuR8vkd5x0teMXGGmiTzdB96DuNRWayM0y8vkP-1KJiPFxKjOXULjuXhLmINIOYn39bQprq~dAtNALoBgd-waZedYgFLvwHDCc9Gui8Cpp41EihlYGNW0cu0vhNFUN79N4DEpO7AtJyrSu5ZjFTAGjLw~lOvhyO2NwQ4RiC4UCKSuM70Fz0BFKTJquIjUNkQ8pBPBYvJRRlRG9HjAcSqAMckC3pvKKlcTJJBAE8GqexV7rdCCIsnasJXle-6DoWrDkY1s1KNbEVH6i1iUEtmFr2IHTpPeFCyWfZ581CAFNRbbUs-MmnZu1tXAYF7I2-oXTH2hXoxCGAAAA
+

 
+
{% trans -%}
 MAKE NOTE OF THE ABOVE DESTINATION KEY, YOURS WILL BE DIFFERENT!
+{%- endtrans %}

 
-FROM    TO    DIALOGUE
+
+{{ _('FROM') }}    {{ _('TO') }}    {{ _('DIALOGUE') }}
 A       C     outhost 127.0.0.1
 C       A     OK outhost set
 A       C     outport 19
 C       A     OK outbound port set
 A       C     start
 C       A     OK tunnel starting
+

 
+
{% trans -%}
 At this point, there was no error, a destination with a nickname of "mouth" 
 is set up. When you contact the destination provided, you actually connect 
-to the CHARGEN service on 19/TCP. 
+to the CHARGEN service on 19/TCP.
+{%- endtrans %}

 
+
{% trans -%}
 Now for the other half, so that we can actually contact this destination.
+{%- endtrans %}

 
-FROM    TO      DIALOGUE
+
+{{ _('FROM') }}    {{ _('TO') }}      {{ _('DIALOGUE') }}
 A       C       setnick ear
 C       A       OK Nickname set to ear
 A       C       newkeys
@@ -127,14 +174,20 @@ A       C       start
 C       A       OK tunnel starting
 A       C       quit
 C       A       OK Bye!
+

 
+
{% trans -%}
 Now all we need to do is telnet into 127.0.0.1, port 37337,
 send the destination key or host address from addressbook we want to contact.
 In this case, we want to contact "mouth", all we do is paste in the
 key and it goes.
+{%- endtrans %}

 
-NOTE: The "quit" command in the command channel does NOT disconnect the tunnels like SAM.
+
{% trans -%}
+NOTE: The "quit" command in the command channel does NOT disconnect the tunnels like SAM.
+{%- endtrans %}

 
+
 # telnet 127.0.0.1 37337
 Trying 127.0.0.1...
 Connected to 127.0.0.1.
@@ -146,20 +199,32 @@ ZMPz1zinTdy3~zGD~f3g9aikZTipujEvvXOEyYfq4Su-mNKerqG710hFbkR6P-xkouVyNQsqWLI8c6ng
 #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
 $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk
 ...
-After a few virtual miles of this spew, press Control-]
+

+
{% trans -%}
+After a few virtual miles of this spew, press Control-]
+{%- endtrans %}

+
 ...
 cdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJK
 defghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKL
 efghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=
 telnet> c
 Connection closed.
+

 
+
{% trans -%}
 Here is what happened...
+{%- endtrans %}

+
 telnet -> ear -> i2p -> mouth -> chargen -.
 telnet <- ear <- i2p <- mouth <-----------'
+

 
+
{% trans -%}
 You can connect to EEPSITES too!
+{%- endtrans %}

 
+
 # telnet 127.0.0.1 37337
 Trying 127.0.0.1...
 Connected to 127.0.0.1.
@@ -186,36 +251,52 @@ Accept-Ranges: bytes
 </html>
 Connection closed by foreign host.
 #
+

 
+
{% trans -%}
 Pretty cool isn't it? Try some other well known EEPSITES if you like, nonexistent ones, 
 etc, to get a feel for what kind of output to expect in different situations. 
 For the most part, it is suggested that you ignore any of the error messages. 
 They would be meaningless to the application, and are only presented for human debugging.
+{%- endtrans %}

 
+
{% trans -%}
 Let's put down our destinations now that we are all done with them.
+{%- endtrans %}

 
+
{% trans -%}
 First, lets see what destination nicknames we have.
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	list
 C	A	DATA NICKNAME: mouth STARTING: false RUNNING: true STOPPING: false KEYS: true QUIET: false INPORT: not_set INHOST: localhost OUTPORT: 19 OUTHOST: 127.0.0.1
 C	A	DATA NICKNAME: ear STARTING: false RUNNING: true STOPPING: false KEYS: true QUIET: false INPORT: 37337 INHOST: 127.0.0.1 OUTPORT: not_set OUTHOST: localhost
 C	A	OK Listing done
+

 
+
{% trans -%}
 Alright, there they are. First, let's remove "mouth".
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	getnick mouth
 C	A	OK Nickname set to mouth
 A	C	stop
 C	A	OK tunnel stopping
 A	C	clear
 C	A	OK cleared
+

 
+
{% trans -%}
 Now to remove "ear", note that this is what happens when you type too fast,
 and shows you what typical ERROR messages looks like.
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	getnick ear
 C	A	OK Nickname set to ear
 A	C	stop
@@ -226,20 +307,31 @@ A	C	clear
 C	A	OK cleared
 A	C	quit
 C	A	OK Bye!
+

 
+
{% trans -%}
 I won't bother to show an example of the receiver end of a bridge
 because it is very simple. There are two possible settings for it, and
 it is toggled with the "quiet" command.
+{%- endtrans %}

+
+
{% trans -%}
 The default is NOT quiet, and the first data to come into your
 listening socket is the destination that is making the contact. It is a
 single line consisting of the BASE64 address followed by a newline.
 Everything after that is for the application to actually consume.
+{%- endtrans %}

+
+
{% trans -%}
 In quiet mode, think of it as a regular Internet connection. No
 extra data comes in at all. It's just as if you are plain connected to
 the regular Internet. This mode allows a form of transparency much like
 is available on the router console tunnel settings pages, so that you
 can use BOB to point a destination at a web server, for example, and
 you would not have to modify the web server at all.
+{%- endtrans %}

+
+
{% trans -%}
 The advantage with using BOB for this is as discussed
 previously. You could schedule random uptimes for the application,
 redirect to a different machine, etc. One use of this may be something
@@ -251,5 +343,5 @@ have to bother shutting it down and restarting it. You could redirect
 and point to a different machine on your LAN while you do updates, or
 point to a set of backup machines depending on what is running, etc,
 etc. Only your imagination limits what you could do with BOB.
-
+{%- endtrans %}

{% endblock %} diff --git a/i2p2www/pages/site/docs/api/i2pcontrol.html b/i2p2www/pages/site/docs/api/i2pcontrol.html index 4053babc..c5052edf 100644 --- a/i2p2www/pages/site/docs/api/i2pcontrol.html +++ b/i2p2www/pages/site/docs/api/i2pcontrol.html @@ -1,86 +1,87 @@ {% extends "global/layout.html" %} {% block title %}I2PControl API{% endblock %} {% block content %} -

I2PControl - Remote Control Service

-

I2P enables a JSONRPC2 interface via the plugin I2PControl. +

{% trans %}I2PControl - Remote Control Service{% endtrans %}

+

{% trans itoopie='http://itoopie.net/' -%} +I2P enables a JSONRPC2 interface via the plugin I2PControl. The aim of the interface is to provide simple way to interface with a running I2P node. A client, itoopie, has been developed in parallel. The JSONRPC2 implementation for the client as well as the plugin is provided by the java libraries JSON-RPC 2.0. A list of implementations of JSON-RPC for various languages can be found at the JSON-RPC wiki. -

-

I2PControl is by default listening on localhost:7650

+{%- endtrans %}

-

API, version 1.

-

+

{% trans %}I2PControl is by default listening on localhost:7650{% endtrans %}

+ +

{% trans %}API, version 1.{% endtrans %}

+

{% trans -%} Parameters are only provided in a named way (maps). +{%- endtrans %}

-

JSON-RPC 2 format

+

{% trans %}JSON-RPC 2 format{% endtrans %}

-Request:
+{{ _('Request:') }}
 {"id":"id", "method":"Method-name","params":{"Param-key-1":"param-value-1", "Param-key-2":"param-value-2", "Token":"**actual token**"}, "jsonrpc":"2.0"}
-Response:
+{{ _('Response:') }}
 {"id":"id","result":{"Result-key-1":"result-value-1","Result-key-2":"result-value-2"},"jsonrpc":"2.0"}
-
-

-