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

Dismantle core node framework #57

Open
gavin-norman-sociomantic opened this issue Jul 17, 2017 · 2 comments
Open

Dismantle core node framework #57

gavin-norman-sociomantic opened this issue Jul 17, 2017 · 2 comments

Comments

@gavin-norman-sociomantic

The node framework in swarm.core provides many useful components for building nodes. Currently, they are all glued together in a very rigid way. There is essentially one class (ChannelsNodeBase) which all nodes must derive from, in order to be able to access the full range of features. As the different types of nodes diverge in their needs, however, this approach is becoming less useful. A nicer approach would be to separate out each of the components so that they can be assembled as required.

Components:

  • Select listener for incoming connections (legacy protocol).
  • Select listener for incoming connections (neo protocol).
  • Select listener for unix socket connections.
  • Per-request stats tracking.
  • Per-action stats tracking.
  • Global I/O stats tracking (bytes sent/received).
  • Node stats logging (this is actually a separate module, but it hooks into the information interfaces INodeInfo and IChannelsNodeInfo).
  • Maintaining a set of storage channels (including a pool of recycled channel instances).

It's interesting that the majority of the really interconnected stuff is for stats tracking / logging. Probably a better approach would be to have separate stats instances for different things (per-request, global I/O, etc), each with a log() method.

@gavin-norman-sociomantic
Copy link
Author

A note on the node information interfaces: it seems that they are unnecessary. For the swarm clients they totally make sense -- you have internal classes that do magic stuff which should absolutely not be exposed to the user, but you want to present the user an interface to the classes with purely non-destructive methods. In the case of the swarm nodes, however, there is no "user" to protect from scary internals.

It seems like these interfaces should just be removed; they serve no purpose and just make things more complicated.

@gavin-norman-sociomantic
Copy link
Author

A note on the node information interfaces: it seems that they are unnecessary.

Actually, they do serve a purpose: the actual node base classes are templated, so accessing the node via one of these information interfaces saves having to store templated references all over the place.

gavin-norman-sociomantic pushed a commit to gavin-norman-sociomantic/swarm that referenced this issue Aug 16, 2017
gavin-norman-sociomantic pushed a commit to gavin-norman-sociomantic/swarm that referenced this issue Aug 23, 2017
gavin-norman-sociomantic pushed a commit to gavin-norman-sociomantic/swarm that referenced this issue Aug 23, 2017
gavin-norman-sociomantic pushed a commit to gavin-norman-sociomantic/swarm that referenced this issue Aug 23, 2017
gavin-norman-sociomantic pushed a commit to gavin-norman-sociomantic/swarm that referenced this issue Aug 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant