Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adaptive node protocol #12

Open
wants to merge 7 commits into
base: master
from

Conversation

@nolash
Copy link
Collaborator

nolash commented Aug 2, 2019

obsoletes #11

@nagydani

This comment has been minimized.

Copy link
Collaborator

nagydani commented Aug 15, 2019

@nolash , I think, the latest commit, namely
1aafb84
is unnecessary. It is contingent on your proposed changes to SWIPs in general, which I think are somewhat controversial. Also, I am wondering why you decided to use a different email address?
Would you be willing to revert that last commit?

@nagydani nagydani requested review from decanus and oskarth Aug 15, 2019
@nolash

This comment has been minimized.

Copy link
Collaborator Author

nolash commented Aug 15, 2019

@nagydani I'm not sure what you mean; the latest commit is bd56875

I don't use that email address, it's only for evil google aliasing.

@nagydani

This comment has been minimized.

Copy link
Collaborator

nagydani commented Aug 20, 2019

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

This comment has been minimized.

Copy link
@decanus

decanus Sep 20, 2019

Member

This seems like it should be in another PR, can we move it please?

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

+1

Copy link
Collaborator

diegomasini left a comment

Please, address the comments to make this SWIP ready to be merged.


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 {

This comment has been minimized.

Copy link
@diegomasini

diegomasini Sep 23, 2019

Collaborator

Missing block code delimiters (```)

OAddr []byte
UAddr []byte
Capabilities *Capabilities
}

This comment has been minimized.

Copy link
@diegomasini

diegomasini Sep 23, 2019

Collaborator

Missing block code delimiters (```)

Copy link
Collaborator

oskarth left a comment

Initial comments in-line

@@ -8,9 +8,9 @@ created: 2019-07-08
updated: 2019-07-09

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

+1


## Abstract

Adaptive node operation means a node should be able to change the capabilities it has according to changes in available resources.

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

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.

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

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

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

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.

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

"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)

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

point to relevant specs like bzz/sync and pss (right below this section)


```
BZZ/SYNC: // (registered by default)
- retrieve 0x00020001

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

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.

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

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:

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

implementation detail, perhaps add to implementation suggestion section to keep spec more concise?

}
```
The network module API can merely consist of:

This comment has been minimized.

Copy link
@oskarth

oskarth Sep 26, 2019

Collaborator

again, "can" - I want to know what it does

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.