implement channel manager service

[dch]

api

• [x] provide a free channel, given the associated root hash
• [x] release a provided channel, given the channel id
• [ ] given a swarm id (hash), return the managing swarm process
• [ ] given a channel, return the managing swarm process
• [ ] separate to channel_manager, get swarm options from that process
• interim we'll have a stubbed convenience function in channel_manager to do that

  spec

-spec channel_manager:acquire(ppspp_options:root_hash()) ->
    ppspp_channel:channel().
-spec channel_manager:release(ppspp_channel:channel()) -> ok.
-spec channel_manager:find_swarm_worker(ppspp_options:root_hash()) ->
   swarm_worker:worker_id().
-spec channel_manager:find_swarm_worker(ppspp_channel:channel()) ->
   swarm_worker:worker_id().
-spec channel_manager:get_swarm_options(ppspp_channel:channel()) ->
    ppspp_options:options().
-spec channel_manager:get_swarm_options(ppspp_options:root_hash()) ->
    ppspp_options:options().

-spec swarm_worker:get_swarm_options(ppspp_channel:channel()) ->
    ppspp_options:options().
-spec swarm_worker:get_swarm_options(ppspp_options:root_hash()) ->
    ppspp_options:options().

notes

• a channel is unique for (belongs to) a single peer, and a single endpoint (client peer), and a single swarm (root hash)
• channels are for the moment assumed to be unique across an erlang cluster (global registration)
• each swarm holds its own state about the required options
• the inquiring process can then query the swarm to retrieve specific options
• should track the owning process for a channel and clean up if it exits
• a future swarm_worker will hold its own swarm options, and register itself
• it will start the peer_worker and pass the swarm options through

[dch]

Quick notes on using gproc:

• add {gproc, ".*", {git, "git://github.com/uwiger/gproc.git", master}}, to rebar.config and run make deps to bring it up to date
• start an erlang node erl -sname fu -pa deps/gproc/ebin and another with erl -remsh fu@continuity -sname wu so we have 2 different processes to play with.

In shell fu@:

Eshell V6.2  (abort with ^G)
(fu@continuity)1> application:start(gproc).
ok
(fu@continuity)2> Hash = "c89800bfc82ed01ed6e3bfd5408c51274491f7d4",  Key = {n,l, Hash}, Options = {some_options}.
{some_options}
(fu@continuity)3> gproc:reg(Key, Options).
true
(fu@continuity)4> %% peek into gproc's store
(fu@continuity)4> gproc:select([{'_', [], ['$$']}]).
[[{n,l,"c89800bfc82ed01ed6e3bfd5408c51274491f7d4"},
  <0.43.0>,
  {some_options}]]
(fu@continuity)5>

and on the other node:

Eshell V6.2  (abort with ^G)
(fu@continuity)1> Hash = "c89800bfc82ed01ed6e3bfd5408c51274491f7d4",  Key = {n,l, Hash}, Options = {some_options}.
{some_options}
(fu@continuity)2> %% lookup the process that registered this hash.
(fu@continuity)2> gproc:lookup_local_name(Hash).
<0.43.0>
(fu@continuity)3> %% grab the key that was registered by this process
(fu@continuity)3> gproc:lookup_value(Key).
{some_options}
(fu@continuity)4>

Obviously one could also send the process a message to retrieve its state as an explicit message, but given that the options of a peer won't ever change this is a reasonable compromise, as it makes updating the existing peer code very easy.