debug.nr

早期freebsd实现

protocol options can be demonstrated.
See the manual pages
\fItpdiscard(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 3 "The Echo Service"
The echo server listens on the transport selector
registered in the ARGO directory service for the application
"echo".
The server accepts incoming connection requests, 
receives TSDUs, and returns the TSDUs to the sender.
It never initiates a disconnect, but expects its peer
to disconnect the transport connection.
.pp
The 
program \fItpping\fR connects to the
echo server.
The transport service and protocol options it uses are those
indicated in the ARGO directory service.
By changing the directory service entry for the 
echo service, each of the transport service options and
protocol options can be demonstrated.
See the manual pages
\fItpping(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 3 "The Remote Login Service"
The remote login server listens on the transport selector
registered in the ARGO directory service for the application
"login".
The server accepts incoming connection requests,
implements the BSD remote login protocol, checks permissions using
the \fC~/.rhosts\fR, and \fC/etc/passwd\fR files, and
uses the ARGO directory service to discover name-to-NSAP-address
mappings.
If the remote user is authorized to log in to the end system on which
the server runs, a login is started.
.pp
The program \fIrlogin.iso\fR connects to the remote login server.
The transport service and protocol options it uses are those
indicated in the ARGO directory service.
By changing the directory service entry for the 
login service, each of the transport service options and
protocol options can be demonstrated.
See the manual pages
\fIrlogin.iso(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 3 "The Remote Shell Service"
The remote shell server listens on the transport selector
registered in the ARGO directory service for the application
"shell".
The server accepts incoming connection requests,
implements the BSD remote command authorization protocol, 
checks permissions using
the \fC~/.rhosts\fR, and \fC/etc/passwd\fR files, and
uses the ARGO directory service to discover name-to-NSAP-address
mappings.
If the remote user is authorized to execute a shell on
the end system on which
the server runs, a shell is started.
.pp
The program \fIrcp.iso\fR connects to the remote shell server to 
effect a remote copy.
The transport service and protocol options it uses are those
indicated in the ARGO directory service.
By changing the directory service entry for the 
shell service, each of the transport service options and
protocol options can be demonstrated.
See the manual pages
\fIrcp.iso(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 3 "The Simple File Transfer Service"
.pp
The last service consists of a pair of programs,
\fItpfileget\fR and
\fItpfileput\fR,
which cooperate to transfer one file.
The passive program, \fItpfileget\fR,
listens on the transport selector registered in the ARGO directory service
to support the application named "tptestsel".
The sending program, \fItpfileput\fR, 
connects to the passive program, transfers in one TSDU
the file named on the \fItpfileput\fR command line, and waits for the
passive end to close the connection.
\fITpfileget\fR 
opens a file of the name given on its command line,
accepts one connection request, receives 
one TSDU, writes the contents of that TSDU to the opened file,
and when it receives the end-of-TSDU indication,
\fItpfileget\fR closes the transport connection.
The transport service options and protocol options used by
\fItpfileput\fR are determined by the ARGO directory service
record that describes the applicaition "tptestsel".
See the manual pages
\fItpfileget(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 3 "Internal TP Testing"
.pp
The methods used to test each of the various functions
of TP are described in this section.
One or more of the services described above were used, while
the TP activity was observed with tracing or debugging or both.
The statistics were cleared before each test and inspected
after each test.
Each test can be run with different protocol and service options,
by changing the transport parameters in records
in the ARGO directory service file.
See the manual pages
\fItpstat(8)\fR,
\fItpmon(8)\fR,
\fItppt(8)\fR,
\fIbark(8)\fR,
\fItp(4p)\fR,
and 
\fIisodir(5)\fR
for more information.
.sh 4 "Normal and Expedited Data Transfer:"
.pp
TSDUs are 
distinguished by the presence or absence of the
EOTSDU bit in the \fIflags\fR parameter of the
\fIsendv()\fR system call.
The data of a TSDU are copied into chains of \fImbufs\fR
in the kernel so that the end of a TSDU lies in an mbuf
with the \fIm_act\fR field non-zero.
The end of a TSDU never lies in the middle of an
mbuf.
This is true on the receiving side as well.
On output, the segmenting function,
the function that copies user data into mbuf chains
reorganizes mbuf chains into TPDUs,
is observed using several debug options
and trace options
in the routines \fIsosend()\fR 
and \fItp_sbsend()\fR.
On input, the reassembling mechanism
is observed in the routine \fItp_stash()\fR.
The debug options 
\fBT.ndata\fR, 
\fBT.sb\fR, and 
\fBT.xpd\fR
print information 
pertinent to this function.
.pp
Expedited data complicates the matter of segmenting
because markers must be kept in the chains of outgoing
TPDUs to indicate the precedence of expedited data TPDUs
over normal data TPDUs.
The pertinent trace options are \fBT.sb\fR and \fBT.ndata\fR.
With the trace and (or) debugging options on,
and with \fItpdiscard\fR running, one can observe the segmentation
and reassembly of TPDUs.
.pp
Using the file transfer programs to transfer a file,
then transferring it back with \fIrcp\fR (the TCP version) if necessary, and
using
\fIdiff\fR, one can see that data are transferred correctly.
The \fBT.input\fR trace option creates a readable hexadecimal dump of incoming TPDUs.
The 
\fBT.emit\fR
trace option creates the same sort of dump for outgoing
TPDUs in \fItp_emit()\fR.
Sequencing
can be observed by using the 
\fBT.ndata\fR
and 
\fBT.input\fR
or 
\fBT.emit\fR
trace options
to see the sequence numbers assigned to TPDUs.
.pp
The
\fBT.drop\fR
debug option causes \fItp_input()\fR
to throw away occasional TPDUs.
(The formula for determining when to discard a TPDU
is ad hoc and simplistic.  It causes TPDUs to be
discarded frequently but not so frequently that the 
receiving side has no chance to recover.)
With tracing on and the file transfer programs running,
resequencing can be observed
and the correctness of the transferred data
can be verified with \fIdiff(1)\fR.
.pp
The use of both normal and extended formats
can be observed with the \fBT.input\fR and \fBT.emit\fR trace options.
.pp
The following statistics are of interest:
.(b
.nf
\fIn\fR connections used extended format
\fIn\fR connections allowed transport expedited data
\fIn\fR connections turned off checksumming
\fIn\fR connections dropped due to retrans limit
\fIn\fR EOT bits on incoming TPDUs
\fIn\fR EOT bits on outgoing TPDUs
\fIn\fR XPD marks discarded
\fIn\fR XPD stopped data flow \fIm\fR times
\fIn\fR DTs out of order
\fIn\fR DTs not in window 
\fIn\fR duplicate DTs
\fIn\fR XPDs not in window
\fIn\fR XPDs w/o credit to stash
\fIn\fR DT (sent)
\fIn\fR DT (received)
\fIn\fR DT (retransmitted)
\fIn\fR XPD (sent)
\fIn\fR XPD (received)
\fIn\fR random DTs dropped
.fi
.)b
.sh 4 "Checksumming, use and non-use:"
.pp
The checksum generation and checking
routines were first written and debugged as user-level
routines before they were modified for kernel use.
The kernel routines may be observed with the 
\fBT.chksum\fR
debug option.
Various sizes of mbufs can be created by creative use of the
ARGO directory service, particularly by changing the value of the
attribute \fItp.tpdusize\fR.
There is no trace option for checksumming.
Checksumming has been used with transfers to and from at least
one other TP implementation.
.pp
The statistics that are pertinent to checksumming are:
.(b
.nf
\fIn\fR connections turned off checksumming
\fIn\fR invalid checksums
.fi
.)b
.sh 4 "Acknowledgment:"
.pp
Acknowledgment can be observed by using the 
debug and trace options
\fBT.aks\fR,
\fBT.akr\fR,
\fBT.input\fR,
\fBT.emit\fR,
and
\fBT.driver\fR.
The transport driver (finite state machine) and the routine 
\fItp_goodack()\fR dump information appropriate to acknowledgments.
If the \fBT.ndata\fR, and \fBT.emit\fR or \fBT.input\fR trace options are used 
along with the \fBT.aks\fR and \fBT.akr\fR trace options,
a complete picture of the data transfer and acknowledgment
activity can be created.
The acknowledgments for expedited data are traced with
the 
\fBT.xpd\fR
trace option.
The routine \fItp_goodXack()\fR and the finite state
machine dump information when the
\fBT.xpd\fR
debug and trace options are used.
To cause expedited data to be generated,
the -e or -E option on the discard programs or the file
transfer programs are used.
To observe the different acknowledgment strategies,
the protocol options were changed in the ARGO directory service.
.pp
The pertinent statistics are:
.(b
.nf
\fIn\fR AK (received)
\fIn\fR AK (sent)
ACK reasons:
\fIn\fR not acked immediately
\fIn\fR strategy==each
\fIn\fR strategy==fullwindow
\fIn\fR duplicate DT
\fIn\fR EOTSDU
\fIn\fR reordered
\fIn\fR user rcvd
\fIn\fR fcc reqd
.fi
.)b
.pp
The smoothed average round trip time is kept
for outgoing TPDUs for each transport connection 
and for the entire TP entity.
The time each TPDU is transmitted is recorded, and when an acknowledgment
arrives, the round trip time is computed for the lowest
sequence number that this AK TPDU acknowledges.
The computation of round trip times can be observed
in a trace with the
\fBT.rtt\fR
option.
.pp
In addition to average round trip times, the kernel
maintains the standard deviation of the round trip times.
This statistic is kept for each connection and for the entire
TP entity.
In fact, four such sets of statistics are kept for the TP entity:
.np
for traffic not on a public data network (PDN) and on the same network as this end system,
.np
for traffic not on a public data network (PDN) and on not the same network as this end system,
.np
for traffic on a public data network (PDN) and on the same network as this end system,
and
.np
for traffic on a public data network (PDN) and not on the same network as this end system.
The determination of whether traffic is on the same network as this end system
is based on the "network portion" of the peer's NSAP-address.
For more information about this, see the section of this document titled
\fB"Network Layer Routing"\fR.
.pp
The smoothed average round trip time statistics for a given
can be observed with the -t option to
\fItpstat(8)\fR.
The global round trip statistics can be observed with  the -s option to
\fItpmon(8)\fR.
.sh 4 "Flow Control:"
.pp
Flow control activity is the transfer of credit information
from end to end and the proper use of that information.
To see that it works properly, one must observe three
things:
the receiving window must shut down and reopen, 
the sender must transmit enough TPDUs to fill the receiver's window 
but no more, and the receiver must renege previously advertised credit.
These three behaviors have been observed as follows.
.pp
Tracing with the 
\fBT.ndata\fR, 
\fBT.aks, \fR
\fBT.akr, \fR
\fBT.emit\fR 
and 
\fBT.input\fR 
trace options