|
All keywords are case-sensitive. Not all keywords must be present.
(However, note that the end keyword at the end of the
file must be present.) If a keyword is not present, internal defaults, which
are the default values described here, will be used. Keyword-value pairs
are specified by:
-
DebugLevel
- Specify the number of error,
warning, and information messages to be generated while the RPL server is
running. The valid range is 0-9. A value of 0 means no message at all,
while a value of 9 will generate the most messages. The default is 0. Note
that it is best to limit the value to 8 or below; use of level 9 may generate
so many debug messages that the performance of the RPL server may be impacted.
-
DebugDest
- A numeric value specifying where to send the messages to:
|
0 = standard output
1 = syslogd
2 = log file
|
The default is 2.
-
MaxClients
- A numeric value specifying the maximum number of simultaneous network boot
clients to be in service. A value of -1 means unlimited except where
system resources is the limiting factor. Any positive value will set a
limit on the number of clients to be in service at the same time unless
system resource constraints come in before the limit. The default is -1.
-
BackGround
- A numeric value indicating whether the RPL server should run in the background
or not. A 0 means run in the background and a 1 means do not run in the
background. The difference is whether the server will relinquish the controlling
terminal or not. The default is 1.
-
FrameSize
- The default size of data frames to be used to send bootfile data to the
network boot clients. This size should not exceed the limits imposed by
the underlying physical media. For ethernet/802.3, the
maximum physical frame size is 1500 octets. The default is 1500. Note that
the protocol overhead of LLC1 and RPL is 32 octets, resulting in a maximum
data length of 1468 octets.
-
LogFile
- The
log file to which messages will be sent if DebugDest
is set to 2 (the default). The default file is var/spool/rpld.log.
-
StartDelay
- The initial delay factor to use to control the speed of downloading. In
the default mode of operation, the downloading process does not wait for
a positive acknowledgment from the client before the next data frame is
sent. In the case of a fast server and slow client, data overrun can result
and requests for retransmission will be frequent. By using a delay factor,
the speed of data transfer is controlled to avoid retransmission requests.
Note that the unit of delay is machine dependent and bears no correlation
with the actual time delayed.
-
DelayGran
- Delay granularity. If the initial delay factor is not suitable and the
rate of downloading is either too fast or too slow, retransmission requests
from the clients will be used to adjust the delay factor either upward (to
slow down the data rate) or downward (to speed up the data rate). The delay
granularity is used as the delay delta for adjustment.
-
end
- Keyword
at the end of the file. It must be present.
|