Manual startup and conifiguring during startup the following Erlang/OTP applications: :cowboy, :syn, :kvs and :n2o.

Example:

iex(1)> Supervisor.which_children(:n2o)
[
  {{:ws, '/ws/chat/1'}, #PID<0.258.0>, :worker, [:n2o_wsnode]},
  {{:ws, '/ws/chat/2'}, #PID<0.257.0>, :worker, [:n2o_wsnode]},
  {{:ws, '/ws/chat/3'}, #PID<0.256.0>, :worker, [:n2o_wsnode]},
  {{:ws, '/ws/chat/4'}, #PID<0.255.0>, :worker, [:n2o_wsnode]},
  {{:caching, 'timer'}, #PID<0.201.0>, :worker, [:n2o]}
]

In example you see two rings: mqtt and ws for MQTT and WebSocket workers respectively.

File config/config.exs should contain proto N2O parameter, the module which contains N2O protocol that will be runned inside ring worker:

config :n2o,
  proto: CHAT.Server,
  ws_server: false

In CHAT application this :n2o_wsnode worker is CHAT.Server module. Also we need to disable WebSocket ring creationg at N2O startup and create it manually during CHAT startup as PI protocol :init function contains SYN registration which is dependency only for CHAT, the higher level that N2O, which is zero-dependency library.

Called when an application is started.

This function is called when an application is started using Application.start/2 (and functions on top of that, such as Application.ensure_started/2). This function should start the top-level process of the application (which should be the top supervisor of the application's supervision tree if the application follows the OTP design principles around supervision).

start_type defines how the application is started:

• :normal - used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another node and the application specification key :start_phases is :undefined.
• {:takeover, node} - used if the application is distributed and is started on the current node because of a failover on the node node.
• {:failover, node} - used if the application is distributed and is started on the current node because of a failover on node node, and the application specification key :start_phases is not :undefined.

start_args are the arguments passed to the application in the :mod specification key (e.g., mod: {MyApp, [:my_args]}).

This function should either return {:ok, pid} or {:ok, pid, state} if startup is successful. pid should be the PID of the top supervisor. state can be an arbitrary term, and if omitted will default to []; if the application is later stopped, state is passed to the stop/1 callback (see the documentation for the c:stop/1 callback for more information).

use Application provides no default implementation for the start/2 callback.

Callback implementation for Application.start/2.