web100srv(8) web100srv(8)
NAME
web100srv - NDT server-side testing and analysis engine.
SYNOPSIS
web100srv [options]
DESCRIPTION
The Network Diagnostic Tester (NDT) tool is a client/server program
that provides network configuration and performance testing to a user's
desktop or laptop computer. The system is composed of a client program
(command line or java applet) and a pair of server programs (a web-
server and a testing/analysis engine).
The NDT server components are deployed on a Web100-enhanced server and
these processes are started at boot time. A simple web server, fakewww,
provides a front end to the testing and analysis engine. It allows any
Java-enabled web browser to access the testing and analysis engine,
eliminating the need to pre-load software on the desktop computer. This
greatly enhances the utility of the system. The testing and analysis
engine, web100srv, exchanges data with a command line or Java applet-
based client program to test the client computer and the network path
between the client and server. A series of specific tests are conducted
with the purpose of identifying well know configuration problems that
adversely affect network performance. The goal is to allow users to
self-test their desktop or laptop computer and produce results that are
acceptable to a site network administrator.
The web100srv program provides the testing and analysis features that
make the NDT an effective diagnostic tool. The basic operation is:
? A client program connects to the server opening a command
channel on the well-know TCP port 3001. This command
channel is maintained throughout the life of the test to
allow the exchange of test results. This client program
may be the Java applet, automatically downloaded via the
web services interface, or a command line program,
web100clt, pre-loaded on the client computer. The server
accepts this request, forks a child process to handle the
specific tests, and goes back to listen for new requests.
There are several operational modes (see options below)
that may cause the child to start a test, handle multiple
simultaneous clients, or immediately terminate the pend-
ing request.
? Once a test request is accepted, the server returns a
pair of TCP port numbers that the client must use for
further testing. The server process does a passive open
on these ports via the listen(2) command. The client per-
forms the active open, via the connect(2) command, to
allow it to operate, even when located behind a NAT or
other filtering firewall. By default, the server uses TCP
port numbers 3002 and 3003 for this testing service.
? Testing begins with the client opening a connection on
port 3003. The server records and returns the negotiated
TCP max segment size, along with the server's view of the
IP addresses used for this connection. These values
allow the client to determine if a NAT or filtering fire-
wall is located in the network path. The connection is
closed and the client records the results for later dis-
play.
? Next, the client opens a connection on port 3002. Data
is streamed from the client to the server for 10 seconds.
The result is a measurement of the achieved throughput
from the client to the server - i.e., the upload direc-
tion. By default, the server fork(2)'s a child process to
monitor the packet dispersion of the packets sent and
received during this test. A simple pcap(3) program notes
the arrival time of each packet and computes a throughput
rate for each pair. These results are then quantized into
a limited number of bins, one for each link technology to
be identified, and a weighted average is also computed.
At the end of the test these bins are returned to the
parent process for analysis.
? Then, the client opens a connection on port 3003. Data
is streamed from the server to the client for 10 seconds.
The result is a measurement of the achieved throughput
from the server to the client - i.e., the download direc-
tion. By default, the server fork(2)'s a child process to
capture another set of packet dispersion events. (Note:
the server process must have enough privileges to perform
this snooping on the network interface.) After the test
stream has finished, the server retrieves a set of Web100
kernel variables and counters. These variables are used
by the analysis engine to determine what, if any, fault
conditions occurred.
? The final step is to analyze the collected data. The
packet dispersion results are used to calculate the bot-
tleneck link technology used on the network path. This
value provides an upper limit on how fast an application
may operate. The current list of detected links is
defined below. Following the link detection, the analysis
engine looks for signs of duplex mismatch and cable
faults that cause non-congestive packet loss. These two
conditions will adversely effect throughput, but may not
show up with simple connectivity testing, allowing them
to remain undetected for long periods of time. The final
step is to analyze the connection for signs of congestion
and full/half duplex operation. These normal conditions
can help identify when problems exist and when the net-
work is operating properly.
OPTIONS
-a Generate an administrator view web page. The NDT server main-
tains a log file that contains the results from every test.
This allows the NDT administrator to examine the test results
when users complain. This option allows the NDT administrator to
make a summary of these results available to the user community
via the web interface. When enabled, this options generates the
results web page.
-d Print debugging information. This option increments the internal
debugging flag, allowing the display of run-time diagnostic mes-
sages. Repeated use of this option increases the amount of
debugging information that will be displayed. Note: debugging
information prints to stderr.
-m Select single or multi-test mode. By default, the NDT operates
in single test mode. This means that only a single client may
run a test at any given time. The NDT administrator may choose
to allow multiple clients to run concurrent tests instead of
this single client mode. Note: doing so allows clients to inter-
fere with each other, possibly congesting the NDT's local net-
work link.
-q Disable FIFO queuing. By default, the NDT operates with a FIFO
queue, allowing multiple clients to request tests. If the server
is currently performing a test, the requesting client is
informed that the server is busy and testing will begin within
xx seconds. The NDT administrator may disable this queuing and
reject test requests while the server is busy. In this mode, the
user must manually request another test.
-r Record Web100 variables when the server is receiving data. By
default, the server does not capture Web100 variables during the
client to server throughput test. There is a minimal amount of
Web100 data collected when TCP is operating in a receive mode.
This option allows the NDT administrator to collect and examine
this Web100 data.
-t Write a tcpdump(8) formatted file to disk. By default, the
server tries to perform a packet dispersion analysis of all data
sent and received on the test ports (3002 and 3003). This
options allows the administrator to capture these data streams
for later analysis. The tcpdump(8) and tcptrace(1) programs can
be used to analyze these trace files.
-x Enable any experimental code. The server program is constantly
being modified and, from time to time, experimental code is
installed. This option allows the NDT administrator to invoke
this code at run time.
-v Print version number and exit.
-b buffer_size
This option allows the NDT administrator to set the TCP send and
receive buffer sizes via the setsockopt(2) function. Values
larger than 64 Kbytes will result in large windows if the
RFC1323 window scaling option is enabled on the client host. By
default, the server uses the system default values. The NDT
administrator may override the system defaults with this option.
-f variable_FN
By default, the /usr/local/ndt/web100_variables file contains a
list of Web100 variables that should be collected by the NDT
server. This options allows the NDT administrator to specifi-
cally define the location and name of this file.
-i device
By default, the NDT server monitors the 1st Ethernet interface
for the packet dispersion testing. This option allows the NDT
administrator to select a different interface.
-l log_FN
By default, the NDT server writes the results of every test to
the /usr/loca/ndt/web100srv.log log file. This option allows the
NDT administrator to define a new location and name for this log
file
-p port #
By default, the NDT server listens for test request on port
3001. This option allows the NDT administrator to change this
port number.
LIMITATIONS
The NDT service is continuing to undergo testing and upgrading. Better
diagnostic algorithms are being developed to improve the accuracy and
reliability of this service.
EXAMPLES
web100srv -a >& /dev/null &
Start server with administrator view enabled
web100srv -ddd
Start server in foreground and enable 3 levels of debug mes-
sages.
SEE ALSO
The http://e2epi.internet2.edu/ndt/ web site, web100clt(1), fakewww(8),
and setsockopt(2).
ACKNOWLEDGMENTS
This material is based, in part, on work supported by the National Sci-
ence Foundation (NSF) under Grant No. ANI-0314723. Any opinions, find-
ings, conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect the views of the
NSF.
$Date: 2004/05/20 21:49:12 $ web100srv(8)
Man(1) output converted with
man2html
