Application developers should review the application +development guide for ideas about the four basic protocols for writing an +application to run over I2P:
here's some content that might help someone who wants to put together an application developer's guide for I2P - I dont have time to polish this up before I leave, but thought it might be of use to someone. Feel free to tear this up, edit like mad, or just read it :)
-Using mihi's I2PTunnel application, you can hook up application instances and -have them talk to each other over standard TCP sockets. In plain client-server -scenarios, this is an effective technique for many simple protocols, but for -distributed systems where each peer may contact a number of other peers (instead -of just a single server), or for systems that expose TCP or IP information within -the communication protocols themselves, there are problems.
+Using mihi's I2PTunnel application, you can hook up +application instances and have them talk to each other over standard TCP +sockets. In plain client-server scenarios, this is an effective technique for +many simple protocols, but for distributed systems where each peer may contact +a number of other peers (instead of just a single server), or for systems that +expose TCP or IP information within the communication protocols themselves, +there are problems.
With I2PTunnel, you need to explicitly instantiate an I2PTunnel for each peer you want to contact - if you are building a distributed instant messenger @@ -122,14 +121,13 @@ application without having to write fragmentation, resends, etc.
SAM is the Simple Anonymous Messaging protocol, allowing an +
SAM is the Simple Anonymous Messaging protocol, allowing an application written in any language to talk to a SAM bridge through a plain TCP socket and have that bridge multiplex all of its I2P traffic, transparently coordinating the encryption/decryption and event based handling. SAM supports three styles of operation:
For applications written in Java, the simplest way to go is to use the libraries that the SAM bridge and I2PTunnel applications use. The streaming functionality is exposed in the 'ministreaming' library, which is centered on the -I2PSocketManager, -the I2PSocket, and the -I2PServerSocket.
+I2PSocketManager, +the I2PSocket, and the +I2PServerSocket.For applications that want to use repliable datagrams, they can be built with the -I2PDatagramMaker +I2PDatagramMaker and parsed on the receiving side by the -I2PDatagramDissector. +I2PDatagramDissector. In turn, these are sent and received through an -I2PSession.
+I2PSession.Applications that want to use raw datagrams simply send directly through the I2PSession's -sendMessage(...) +sendMessage(...) method, receiving notification of available messages through the -I2PSessionListener and +I2PSessionListener and then fetching those messages by calling -receiveMessage(...). +receiveMessage(...).
I2CP itself is a language independent protocol, but to implement an I2CP library in something other -than Java there is a significant amount of code to be written (encryption routines, object marshalling, -asynchronous message handling, etc). While someone could write an I2CP library in C or something else, -it would most likely be more useful to write a C SAM library instead.
+I2CP itself is a language independent protocol, but to implement an I2CP library +in something other than Java there is a significant amount of code to be written (encryption routines, +object marshalling, asynchronous message handling, etc). While someone could write an I2CP library in +C or something else, it would most likely be more useful to use the C SAM library instead.