{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/go-ethereum/issues/1970","labels_url":"https://api.github.com/repos/ethereum/go-ethereum/issues/1970/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/go-ethereum/issues/1970/comments","events_url":"https://api.github.com/repos/ethereum/go-ethereum/issues/1970/events","html_url":"https://github.com/ethereum/go-ethereum/pull/1970","id":115403785,"number":1970,"title":"Customizable protocol stacks","user":{"login":"karalabe","id":129561,"avatar_url":"https://avatars.githubusercontent.com/u/129561?v=3","gravatar_id":"","url":"https://api.github.com/users/karalabe","html_url":"https://github.com/karalabe","followers_url":"https://api.github.com/users/karalabe/followers","following_url":"https://api.github.com/users/karalabe/following{/other_user}","gists_url":"https://api.github.com/users/karalabe/gists{/gist_id}","starred_url":"https://api.github.com/users/karalabe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/karalabe/subscriptions","organizations_url":"https://api.github.com/users/karalabe/orgs","repos_url":"https://api.github.com/users/karalabe/repos","events_url":"https://api.github.com/users/karalabe/events{/privacy}","received_events_url":"https://api.github.com/users/karalabe/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ethereum/go-ethereum/labels/review","name":"review","color":"fad8c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-11-05T23:58:51Z","updated_at":"2015-11-24T01:21:36Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/ethereum/go-ethereum/pulls/1970","html_url":"https://github.com/ethereum/go-ethereum/pull/1970","diff_url":"https://github.com/ethereum/go-ethereum/pull/1970.diff","patch_url":"https://github.com/ethereum/go-ethereum/pull/1970.patch"},"body":"*The goal of this PR is to allow assembling custom protocol stacks, with each and every desired protocol individually configurable, and individually runnable. (i.e. [this](https://github.com/karalabe/go-ethereum/blob/customizable-protocol-stacks/node/node_example_test.go))*\r\n\r\nThe existing protocol design is centered around the `eth` package and the Ethereum protocol, with all others (Whisper, Swarm, Light) needing to plug into this one gigantic central component. This caused the `eth` package to grow huge and out of scope. This PR splits out all generic protocol independent stuff into a separate package (`node`), which would essentially be a life cycle manager for all the protocols a user wishes to run. This allows a user to create a `Node`, and register any combination of protocols (`Service`) it wishes, also enabling one to run arbitrary protocols (e.g. Whisper) without `eth`.\r\n\r\n - [x] Introduce a `Node` construct, that acts as a life cycle manager to arbitrarily many, independent protocols (or services, to make it a bit clearer). Any protocol implementing a simple interface may be registered, and the `Node` will take care of instantiating and executing it.\r\n - [x] The `Node` is capable of starting, restarting and stopping all registered services. Even though the `Node` is capable of restarting a service, the implementation of said service/protocol does *not* have to support it. Instead of requiring services to clean up their internal state properly between restarts (which can be very error prone), the `Node` instantiates new versions of the services whenever one is to be started. Similarly, a `Node` can also restart the underlying `p2p.Server` by creating a new instance.\r\n - [x] The introduced `Node` is responsible from now on for handling the generic contents of the data dir, and even ensuring the data dir exists before any of the services depending on it are instantiated. Whenever a node is created, an associated data dir is either accessed (if it exists), created (if the user specified one), or a temporary one generated. Similarly, the generic contents of the data dir (node key, static/trusted nodes) are handled by the `Node` and never leaked out into any of the service implementations.\r\n - [x] P2P networking related fields that cannot be automatically derived are passed to a `Node` upon creation via a set of configuration values (`Config`), which are mostly forwarded to the underlying `p2p.Server.`\r\n - [x] Support is added for ephemeral data dirs, ensuring that if no datadir is specified, all databases created by individual protocols are in-memory only, and further that the nodekey is also never written to disk. The keystore needs to be still reworked to support ephemeral storage, but that is a bigger PR, so it's for another day."},"comment":{"url":"https://api.github.com/repos/ethereum/go-ethereum/issues/comments/159121336","html_url":"https://github.com/ethereum/go-ethereum/pull/1970#issuecomment-159121336","issue_url":"https://api.github.com/repos/ethereum/go-ethereum/issues/1970","id":159121336,"user":{"login":"zelig","id":769725,"avatar_url":"https://avatars.githubusercontent.com/u/769725?v=3","gravatar_id":"","url":"https://api.github.com/users/zelig","html_url":"https://github.com/zelig","followers_url":"https://api.github.com/users/zelig/followers","following_url":"https://api.github.com/users/zelig/following{/other_user}","gists_url":"https://api.github.com/users/zelig/gists{/gist_id}","starred_url":"https://api.github.com/users/zelig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zelig/subscriptions","organizations_url":"https://api.github.com/users/zelig/orgs","repos_url":"https://api.github.com/users/zelig/repos","events_url":"https://api.github.com/users/zelig/events{/privacy}","received_events_url":"https://api.github.com/users/zelig/received_events","type":"User","site_admin":false},"created_at":"2015-11-24T01:21:36Z","updated_at":"2015-11-24T01:21:36Z","body":"scary\r\namazing\r\nwish you held off big changes in unrelated parts like account unlocking.\r\nyet to test it out with bzz :)"}}