forked from I2P_Developers/i2p.www
prop. 144 more implementation notes
This commit is contained in:
@ -3207,6 +3207,30 @@ non-mod-16 padding, things will need to be done differently.
|
||||
|
||||
|
||||
|
||||
Protocol-layer Responses
|
||||
-------------------------
|
||||
|
||||
Initial implementations rely on bidirectional traffic at the higher layers.
|
||||
That is, the implementations assume that traffic in the opposite direction
|
||||
will soon be transmitted, which will force any required response at the ECIES layer.
|
||||
|
||||
However, certain traffic may be unidirectional or very low bandwidth,
|
||||
such that there is no higher-layer traffic to generate a timely response.
|
||||
|
||||
Receipt of NS and NSR messages require a response;
|
||||
receipt of ACK Request and Next Key blocks also require a response.
|
||||
|
||||
A sophisticated implementation may start a timer when one of these
|
||||
messages is received which requires a response,
|
||||
and generate an "empty" (no Garlic Clove block) response
|
||||
at the ECIES layer
|
||||
if no reverse traffic is sent in a short period of time (e.g. 1 second).
|
||||
|
||||
It may also be appropriate for an even shorter timeout for
|
||||
responses to NS and NSR messages, to shift the traffic to
|
||||
the efficient ES messages as soon as possible.
|
||||
|
||||
|
||||
|
||||
Analysis
|
||||
========
|
||||
|
Reference in New Issue
Block a user