monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-11-05 16:07:36 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
monero-site/_i18n/es/resources/moneropedia/message.md
el00ruobuob 4c1e8dd858
Moneropedia relocalized 
+ correction on Italian Account
+ Removed leftover miners.md (replaced by mining.md)
+ Removed Dust and update Copyright
+ Code improvement to avoid reading the config file and to use the builtin jekyll config variable passed in the content
+ Ammount.md:25/26 glitch "\@transaction-privacy" corrected. PL to be checked twice.
+ Italian ammount.md moneropedia links corrected (terms added to destination entries, unnecessary markdown links removed)
+ Polish corrections
+ extend ruby \word-boundary in regex to match `-based` `-like` `-form`
+ Updated readme according to the new way to add or translate a moneropedia entry
+ fix mining with CryptoNight variant
+ rebased to include AR
+ chery picked #820 to avoid conflicts
2018-08-03 06:34:28 +02:00

1.7 KiB
Raw Blame History

entry tags terms summary
Message
kovri
Message
Messages
The mechanisms in which information travels within I2P

{% include untranslated.html %}

The Basics

Messages (which exist on top of the @transports layer), contain varying types of information that are needed for the network but, most importantly, everything you see, do, send, or receive, will come and go in the form of messages.

There are 2 essential types of messages in @I2P:

  • @Tunnel messages
  • @I2NP messages

Essentially: @tunnel messages contain @I2NP message fragments which are then reassembled at certain points within a @tunnel's path.

In-depth information

@I2NP messages have a close relationship with @tunnel @messages so it is easy to get the term messages confused when reading @Java-I2P specifications:

  1. First, the tunnel gateway accumulates a number of I2NP messages and preprocesses them into tunnel messages for delivery.
  2. Next, that gateway encrypts that preprocessed data, then forwards it to the first hop.
  3. That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't a duplicate, then forward it on to the next peer.
  4. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages originally bundled by the gateway are reassembled and forwarded on as requested.

Notes

  • @I2NP @messages need to be fragmented because they are variable in size (from 0 to almost 64 KB) and @tunnel @messages are fixed-size (approximately 1 KB).
  • For details and specifications, visit the I2NP spec and Tunnel Message spec