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
Choose a base branch
from

Conversation

nolash
Copy link
Collaborator

@nolash nolash commented Aug 2, 2019

obsoletes #11

@nagydani
Copy link
Collaborator

@nagydani 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
Copy link
Collaborator Author

@nolash 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
Copy link
Collaborator

@nagydani 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
Copy link

@decanus decanus Sep 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor

@diegomasini 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 {
Copy link
Contributor

@diegomasini diegomasini Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing block code delimiters (```)

OAddr []byte
UAddr []byte
Capabilities *Capabilities
}
Copy link
Contributor

@diegomasini diegomasini Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing block code delimiters (```)

Copy link

@oskarth oskarth left a comment

Initial comments in-line

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

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


## Abstract

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

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

}
```

The network module API can merely consist of:
Copy link

@oskarth oskarth Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants