rfc672.txt

RFC 相关的技术文档

Each TIP is responsible for maintaining in its memory the cells
indicating the connect time and the number of messages sent for each
of its current users. These cells are incremented by the TIP for
every quantum of connect time and message sent, as the case may be.
This is the data generation phase. Periodically, the TIP will scan
all its active counters, and along with each user ID code, pack the
accumulated data into one network message (i.e. less than 8K bits).
The TIP then transmits this data to a set of Accounting Server
processes residing throughout the network. The data transfer is
over a specially designated host-host link. The accounting servers
utilize the raw network message facility of TENEX 1.32 in order to
directly access that link. When an ACTSER receives a data message
from a TIP, it buffers the data and replies by returning the entire
message to the originating TIP. The TIP responds with a positive
acknowledgement ("go ahead") to the first ACTSER which returns the
data, and responds with a negative acknowledgement ("discard") to
all subsequent ACTSER data return messages for this series of
transfers. If the TIP does not receive a reply from any ACTSER, it
accumulates new data (i.e. the TIP has all the while been
incrementing its local counters to reflect the increased connect
time and message count; the current values will comprise new data
transfers) and sends the new data to the Accounting Server
processes. When an ACTSER receives a positive acknowledgement from
a TIP (i.e. "go ahead"), it appends the appropriate parts of the
buffered data to the locally maintained accounting information file.
On receiving a negative acknowledgement from the TIP (i.e.
"discard"), the ACTSER discards the data buffered for this TIP. In
-addition, when the TIP responds with a "go ahead" to the first
ACTSER which has accepted the data (acknowledged by returning the
data along with the "I've got it"), the TIP decrements the connect
time and message counters for each user by the amount indicated in
the data returned by the ACTSER. This data will already be
accounted for in the intermediate accounting files.

As an aid in determining which ACTSER replies are to current
requests, and which are tardy replies to old requests, the TIP

                                      -6-
maintains a sequence number indicator, and appends this number to
each data message sent to an ACTSER. On receiving a reply from an
ACTSER, the TIP merely checks the returned sequence number to see if
this is the first reply to the current set of TIP requests. If the
returned sequence number is the same as the current sequence number,
then this is the first reply; a positive acknowledgement is sent
off, the counters are decremented by the returned data, and the
sequence number is incremented. If the returned sequence number is
not the same as the current one (i.e. not the one we are now
seeking a reply for) then a negative acknowledgement is sent to the
replying ACTSER. After a positive acknowledgement to an ACTSER (and
the implied incrementing of the sequence number), the TIP can wait
for more information to accumulate, and then start transmitting
again using the new sequence number.


Further Clarification of the Protocol


There are a number of points concerning the protocol that
should be noted.

1. The data generator (TIP) can send different (i.e. updated
versions) data to different data collectors (accounting servers) as
part of the same logical transmission sequence. This is possible
because the TIP does not account for the data sent until it receives
the acknowledgement of the data echo. This strategy relieves the
TIP of any buffering in conjunction with re-transmission of data
which hasn't been acknowledged.

2. A new data request to an accounting server from a TIP will
also serve as a negative acknowledgement concerning any data already
buffered by the ACTSER for that TIP, but not yet acknowledged. The
old data will be discarded, and the new data will be buffered and
echoed as an acknowledgement. This allows the TIP the option of not
sending a negative acknowledgement when it is not convenient to do
so, without having to remember that it must be sent at a later time.
There is one exception to this convention. If the new data message
has the same sequence number as the old buffered message, then the
new data must be discarded, and the old data kept and re-echoed.
This is to prevent a slow acknowledgement to the old data from being
accepted by the TIP, after the TIP has already sent the new data to
the slow host. This caveat can be avoided if the TIP does not
resend to a non-responding server within the time period that a
message could possibly be stuck in the network, but could still be
delivered. Ignoring this situation may result in some accounting
data being counted twice. Because of the rule to keep old data when
confronted with matching sequence numbers, on restarting after a
crash, the TIP should send a "discard" message to all servers in
order to clear any data which has been buffered for it prior to the
crash. An alternative to this would be for the TIP to initialize
its sequence number from a varying source such as time of day.

3. The accounting server similarly need not acknowledge receipt
of data (by echoing) if it finds itself otherwise occupied. This
will mean that the ACTSER is not buffering the data, and hence is
not a candidate for entering the data into the file. However, the

                                      -7-
TIP may try this ACTSER at a later time (even with the same data),
with no ill effects.

4. Because of 2 and 3 above, the protocol is robust with respect
to lost or garbled transmissions of TIP data requests and accounting
server echo replies. That is, in the event of loss of such a
message, a re-transmission will occur as the normal procedure.

5. There is no synchronization problem with respect to the
sequence number used for duplicate detection, since this number is
maintained only at the TIP site. The accounting server merely
echoes the sequence number it has received as part of the data.

6. There are, however, some constraints on the size of the
sequence number field. It must be large enough so that ALL traces
of the previous use of a given sequence number are totally reMoved
from the network before the number is re-used by the TIP. The
sequence number is modulo the size of the largest number represented
by the number of bits allocated, and is cyclic. Problems generally
arise when a host proceeds from a service interruption while it was
holding on to a reply. If during the service interruption, we have
cycled through our sequence numbers exactly N times (where N is any
integer), this VERY tardy reply could be mistaken for a reply to the
new data, which has the same sequence number (i.e. N revolutions of
sequence numbers later). By utilizing a sufficiently large sequence
number field (16 bits), and by allowing sufficient time between
instances of sending new data, we can effectively reduce the
probability of such an error to zero.

7. Since the data involved in this problem is the source of
accounting information, care must be taken to avoid duplicate
entries. This must be done at the expense of potentially losing
data in certain instances. Other than the obvious TIP malfunction,
there are two known ways of losing data. One is the situation where
no accounting server responds to a TIP for an extended period of
time causing the TIP counters to overflow (highly unlikely if there
are sufficient Accounting Servers). In this case, the TIP can hold
the counters at their maximum value until a server comes up, thereby
keeping the lost accounting data at its minimum. The other
situation results from adapting the protocol to our insistence on no
duplicate data in the incremental files. We are vulnerable to data
loss with no recourse from the time the server receives the "go
ahead" to update the file with the buffered data (i.e. positive
acknowledgement) until the time the update is completed and the file
is closed. An accounting server crash during this period will cause
that accounting data to be lost. In our initial implementation, we
have slightly extended this period of vulnerability in order to save
the TIP from having to buffer the acknowledged data for a short
period of time. By updating TIP counters from the returned data in
parallel with sending the "go ahead" acknowledgement, we relieve the
TIP of the burden of buffering this data until the Request for Next
Message (RFNM) from the accounting server IMP is received. This
adds slightly to our period of vulnerability to malfunction, moving
the beginning of the period from the point when the ACTSER host
receives the "go ahead", back to the point when the TIP sends off

                                      -8-

the "go ahead" (i.e. a period of one network transit time plus some
IMP processing time). However, loss of data in this period is
detectable through the Host Dead or Incomplete Transmission return
in place of the RFNM. We intend to record such occurrences with the

Network Control Center. If this data loss becomes intolerable, the
TIP program will be modified to await the RFNM for the positive
acknowledgement before updating its counters. In such a case, if
the RFNM does not come, the TIP can discard the buffered data and
re-transmit new data to other servers.

8. There is adequate protection against the entry of forged data
into the intermediate accounting files. This is primarily due to
the system enforced limited access to Host-Imp messages and
Host-Host links. In addition, messages received on such designated
limited access links can be easily verified as coming from a TIP.
The IMP subnet appends the signature (address) of the sending host
to all of its messages, so there can be no forging. The Accounting
Server is in a position to check if the source of the message is in
fact a TIP data generator.


Current Parameters of the Protocol


In the initial implementation, the TIP sends its accumulated
accounting data about once every half hour. If it gets no positive
acknowledgement, it tries to send with greater frequency (about
every 5 minutes) until it finally succeeds. It can then return to
the normal waiting period. (A TIP user logout introduces an
exception to this behavior. In order to re-use the TIP port and its
associated counters as soon as possible, a user terminating his TIP
session causes the accounting data to be sent immediately).
initially, our implementation calls for each TIP to remember a
"favored" accounting server. At the wait period expiration, the TIP
will try to deposit the data at its "favored" site. If successful
within a short timeout period, this site remains the favored site,
and the wait interval is reset. If unsuccessful within the short
timeout, the data can be sent to all servers*. The one replying
first will update its file with the data and also become the
"favored" server for this TIP. With these parameters, a host would
have to undergo a proceedable service interruption of more than a
year in order for the potential sequence number problem outlined in
(6) above to occur.


Concluding Remarks


When the implementation is complete, we will have a general
data accumulation and collection system which can be used to gather
a wide variety of information. The protocol as outlined is geared
to gathering data which is either independent of the previously
accumulated data items (e.g. recording names), or data which
adheres to a commutative relationship (e.g. counting). This is a

                                      -9-

consequence of the policy of retransmission of different versions of
the data to different potential collectors (to relieve TIP buffering
problems).

In the specified version of the protocol, care was taken to
avoid duplicate data entries, at the cost of possibly losing some
data through collector malfunction. Data collection problems which
require avoiding such loss (at the cost of possible duplication of
some data items) can easily be accommodated with a slight adjustment
to the protocol. Collected data which does not adhere to the
commutative relationship indicated above, can also be handled by
utilizing more buffer space at the data generator sites.


The sequence number can be incremented for this new set of data
messages, and the new data can also be sent to the slow host. In
this way we won't be giving the tardy response from the old favored
host unfair advantage in determining which server can respond most
quickly. If there is no reply to this series of messages, the TIP
can continue to resend the new data. However, the sequence number
should not be incremented, since no reply was received, and since
indiscriminate incrementing of the sequence number increases the
chance of recycling during the lifetime of a message.

































                                     -10-