Adaptive node protocol #12
Conversation
|
Okay, then it's not the latest, but it is the commit that I linked, which makes it compliant with the changes in the template that are still pending. |
| @@ -8,9 +8,9 @@ created: 2019-07-08 | |||
| updated: 2019-07-09 | |||
There was a problem hiding this comment.
This seems like it should be in another PR, can we move it please?
|
|
||
| Furthermore, the bzz handshake message itself should also embed this message instead of the `Light` field that is currently there. Incidentally, in the golang implementation, the `BzzAddr` object transmitted in the bzz handshake is also (part of) the peer record stored by the kademlia peer database. A practical approach is therefore to embed the `Capabilities` information in the same structure. `BzzAddr` thus becomes: | ||
|
|
||
| type BzzAddr struct { |
There was a problem hiding this comment.
Missing block code delimiters (```)
| OAddr []byte | ||
| UAddr []byte | ||
| Capabilities *Capabilities | ||
| } |
There was a problem hiding this comment.
Missing block code delimiters (```)
| @@ -8,9 +8,9 @@ created: 2019-07-08 | |||
| updated: 2019-07-09 | |||
|
|
||
| ## Abstract | ||
|
|
||
| Adaptive node operation means a node should be able to change the capabilities it has according to changes in available resources. |
There was a problem hiding this comment.
I'd specify, "available resources, such as bandwidth, connectivity ,...". This helps guide the reader what it's about
|
|
||
| ## Specification | ||
|
|
||
| Upon initial connection, capabilities can be transmitted already within the handshake message. |
There was a problem hiding this comment.
Perhaps this can point to spec that outline the handshake message?
|
|
||
| The peers of the node may need to adjust their behavior towards the node when these capabilities change. Therefore, a protocol is required to inform the peers of changes in capabilities. | ||
|
|
||
| ## Specification |
There was a problem hiding this comment.
The first part reads more like an introduction, perhaps it can be under such a header? Then more clear definitions under Definitions header, Flow, Wire/data layout etc
|
|
||
| Capabilities are combinational. Some combination may make more sense than other. Interpreting which combinations are feasible and which are not should be handled by respective nodes, and not be hardwired in the protocol. | ||
|
|
||
| For this reason, a bit vector seems the most logical choice. The bit vector can represent the adaptive node operation state within the node, and be embedded into the protocol message as-is. |
There was a problem hiding this comment.
"seems" is a bit a of a weasel word in a spec. Better to just state what it does
| For the individually capability flags we will initially be choosing from, we can see an example of two distinct byte pairs representing tematic categories: | ||
|
|
||
| ``` | ||
| BZZ/SYNC: // (registered by default) |
There was a problem hiding this comment.
point to relevant specs like bzz/sync and pss (right below this section)
|
|
||
| ``` | ||
| BZZ/SYNC: // (registered by default) | ||
| - retrieve 0x00020001 |
There was a problem hiding this comment.
all these capabilities should be elaborated on right after in terms of what they mean
| Capabilities *Capabilities | ||
| } | ||
|
|
||
| Consequently the `LightNode` flag is removed from the `HandshakeMsg` message. |
There was a problem hiding this comment.
this is hard to parse, "is removed"? the spec should state what is the case, if things are changing or there's a diff from previous versions, I suggest we call that out in a separate section
| } | ||
| ``` | ||
|
|
||
| For simplicity, arrays of bools are used to represent the flags in interfacing code. In the JSON-RPC API a `Capability` is represented in the following manner: |
There was a problem hiding this comment.
implementation detail, perhaps add to implementation suggestion section to keep spec more concise?
| } | ||
| ``` | ||
|
|
||
| The network module API can merely consist of: |
There was a problem hiding this comment.
again, "can" - I want to know what it does
crtahlin
added
the
check-SWIP-status
obsoletes #11