==== Master Setup ====

A master is enabled by setting one or both variables

<code>
	set feature(nbs1server)         1
	set feature(nbs2server)         1
</code>

in

  * features.conf

No further steps are required for a machine to act as master.

A more specialized master mode involves using
a pure memory-based spool instead of the disk-based spool that is
normally used. Such a mode is suitable for a setup in which
one machine (the master) will act exclusively as an ingest machine
without doing any processing itself, that will feed one or more
processing machines that are configured as slaves.

For configuring this specialized master mode, the variable

<code>
	feature(spooltype)
</code>

must be set appropriately in //features.conf//. See
[[projects:nbsp:howtos:mspoolbdb.readme|mspoolbdb.readme]].

== NOTE ==

One important consideration to take into account in a master-slave
configuration is the latency of the connection between the two machines.
Inside a LAN there is not much to worry about. The default settings
have been chosen with that particular case in mind. But in a connection
accross a WAN the latency can have various consequences, including
the client queues growing and the connections being dropped.

For the first problem the netfilter can be used to limit the number
of products to send to the client. For the second problem, the parameters

<code>
	client_write_timeout_ms
	client_write_timeout_retry
	client_reconnect_wait_sleep_secs
	client_reconnect_wait_sleep_retry
</code>
can be used adjusted in //nbspd.conf// to control the timeout limits
in the master respectively.

Starting with nbsp-2.0, after a client disconnects for some reason,
the server will keep the client's queue state for the amount of time
indicated in //client_reconnect_wait_sleep_secs//, and then check if that same
client has connected again. It the client remains disconnected, it will
repeat that loop until the number of times indicated in
//client_reconnect_wait_sleep_retry// is reached. If the client has connected
again in any of those cycles, then the server resumes the transmission to
the client at the point where the transmision was suspended. Otherwise
the client's queue state is deleted and if that same client connects
again it will be treated as an entirely new connection.
Those parameters can also be set on a per-client basis through the
variable //clientoptions// in the **nbspd.conf** configuration file.

See also
[[projects:nbsp:howtos:slave-setup.readme|slave-setup.readme]]
and
[[http://www.noaaport.net/files/nbsp-ex/netfilter.conf-ex|netfilter.conf]].