Přehled
I2P síťový protokol (I2NP), který je umístěn mezi I2CP a různými přenosovými protokoly I2P, spravuje směrování a mixování zpráv mezi směrovači, stejně jako výběr přenosových protokolů pro komunikaci se sousedem, pokud je podporováno více společných přenosových protokolů.
Definice I2NP
Zprávy I2NP (I2P Network Protocol) lze použít pro zprávy typu jedno skoknutí, směrovač-směrovač, bod-bod. Šifrováním a zabalením zpráv do jiných zpráv je lze bezpečným způsobem odeslat přes více skoků až k cílovému místu určení. Priorita se používá pouze lokálně na původním místě, tj. při zařazování do fronty pro odchozí doručení.
Uvedené priority nemusí být aktuální a mohou být změněny. Implementace fronty priorit se může lišit.
Formát zprávy
Následující tabulka uvádí tradiční 16bajtovou hlavičku používanou v NTCP. Přenosy SSU a NTCP2 používají upravené hlavičky.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
Maximální počet fragmentů je 64 a zpráva nemusí být dokonale zarovnána, takže musí teoreticky vejít do 63 fragmentů.
Maximální velikost počátečního fragmentu je 956 bajtů (za předpokladu doručování přes TUNNEL); maximální velikost následného fragmentu je 996 bajtů. Celková maximální velikost je tedy přibližně 956 + (62 × 996) = 62708 bajtů, neboli 61,2 KB.
Kromě toho mohou mít přenosy další omezení. Limit NTCP je 16 KB - 6 = 16378 bajtů. Limit SSU je přibližně 32 KB. Limit NTCP2 je přibližně 64 KB - 20 = 65516 bajtů, což je vyšší hodnota, než jakou může tunel podporovat.
Vezměte prosím na vědomí, že to nejsou limity pro datagramy, které vidí klient, protože směrovač může seskupit reply leaseset a/nebo session tags spolu se zprávou klienta do jedné garlic zprávy. Leaseset a tagy dohromady mohou přidat přibližně 5,5 KB. Aktuální limit pro datagramy je proto přibližně 10 KB. Tento limit bude zvýšen v budoucí verzi.
Typy zpráv
Vyšší číslo priority znamená vyšší prioritu. Většina provozu jsou TunnelDataMessages (priorita 400), takže cokoli nad 400 je v podstatě vysoká priorita a cokoli pod tím je nízká priorita. Dále si také povšimněte, že mnoho zpráv je obecně směrováno přes průzkumné tunely, nikoli klientské tunely, a proto nemusí být ve stejné frontě, pokud se první skoky náhodou neshodují na stejném peeru.
Také ne všechny typy zpráv jsou odesílány nešifrovaně. Například při testování tunelu router zabalí DeliveryStatusMessage, která je zabalena v GarlicMessage, která je zase zabalena v DataMessage.
| Message | Type | Payload Length | Priority | Comments |
|---|---|---|---|---|
| DatabaseLookupMessage | 2 | 500 | May vary | |
| DatabaseSearchReplyMessage | 3 | Typ. 161 | 300 | Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. |
| DatabaseStoreMessage | 1 | Varies | 460 | Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo. |
| DataMessage | 20 | 4 - 62080 | 425 | Priority may vary on a per-destination basis |
| DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
| GarlicMessage | 11 | Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router | ||
| TunnelBuildMessage | 21 | 4224 | 500 | |
| TunnelBuildReplyMessage | 22 | 4224 | 300 | |
| TunnelDataMessage | 18 | 1028 | 400 | The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was reduced to 200 as of release 0.6.1.33. Outbound gateway messages (i.e. those originated locally) remains at 400. |
| TunnelGatewayMessage | 19 | 300/400 | ||
| VariableTunnelBuildMessage | 23 | 1057 - 4225 | 500 | Shorter TunnelBuildMessage as of 0.7.12 |
| VariableTunnelBuildReplyMessage | 24 | 1057 - 4225 | 300 | Shorter TunnelBuildReplyMessage as of 0.7.12 |
| Others (Types 0, 4-9, 12) | 0, 4-9, 12 | Obsolete, Unused |
Kompletní specifikaci protokolu naleznete na stránce specifikace I2NP . Viz také stránka specifikace běžných datových struktur .
Budoucí práce
Není jasné, zda je současný systém priorit obecně účinný a zda by měly být priority jednotlivých zpráv dále upraveny. Toto je téma pro další výzkum, analýzu a testování.