As per Relevance of the word receiving, we have this rfc below:
Network Working Group David D.
Request for Comments: 969 Mark L.
Lixia
M. I. T. Laboratory for Computer
December 1985
NETBLT: A Bulk Data Transfer
1. STATUS OF THIS
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
This is a preliminary discussion of the NETBLT protocol. It
published for discussion and comment, and does not constitute
standard. As the proposal may change, implementation of
document is not advised. Distribution of this memo is unlimited
2.
NETBLT (Network Block Transfer) is a transport level
intended for the rapid transfer of a large quantity of data
computers. It provides a transfer that is reliable and
controlled, and is structured to provide maximum throughput over
wide variety of networks
The protocol works by opening a connection between two clients
sender and the receiver), transferring the data in a series of
data aggregates called buffers, and then closing the connection
Because the amount of data to be transferred can be
large, the client is not required to provide at once all the data
the protocol module. Instead, the data is provided by the client
buffers. The NETBLT layer transfers each buffer as a sequence
packets, but since each buffer is composed of a large number
packets, the per-buffer interaction between NETBLT and its client
far more efficient than a per-packet interaction would be
In its simplest form, a NETBLT transfer works as follows.
sending client loads a buffer of data and calls down to the
layer to transfer it. The NETBLT layer breaks the buffer up
packets and sends these packets across the network in
datagrams. The receiving NETBLT layer loads these packets into
matching buffer provided by the receiving client. When the
packet in the buffer has been transmitted, the receiving
checks to see that all packets in that buffer have arrived. If
packets are missing, the receiving NETBLT requests that they
resent. When the buffer has been completely transmitted,
receiving client is notified by its NETBLT layer. The
client disposes of the buffer and provides a new buffer to
more data. The receiving NETBLT notifies the sender that the
arrived, and the sender prepares and sends the next buffer in
Clark & Lambert & Zhang [Page 1]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
same manner. This continues until all buffers have been sent,
which time the sender notifies the receiver that the transmission
been completed. The connection is then closed
As described above, the NETBLT protocol is "lock-step"; action
halted after a buffer is transmitted, and begins again
confirmation is received from the receiver of data. NETBLT
for multiple buffering, in which several buffers can be
concurrently. Multiple buffering makes packet flow
continuous and can improve performance markedly
The remainder of this document describes NETBLT in detail. The
sections describe the philosophy behind a number of
features: packetization, flow control, reliability, and
management. The final sections describe the protocol format
3. BUFFERS AND
NETBLT is designed to permit transfer of an essentially
amount of data between two clients. During connection setup
sending NETBLT can optionally inform the receiving NETBLT of
transfer size; the maximum transfer length is imposed by the
width, and is 2**32 bytes. This limit should permit any
application. The transfer size parameter is for the use of
receiving client; the receiving NETBLT makes no use of it. A
receiver accepts data until told by the sender that the transfer
complete
The data to be sent must be broken up into buffers by the client
Each buffer must be the same size, save for the last buffer.
connection setup, the sending and receiving NETBLTs negotiate
buffer size, based on limits provided by the clients. Buffer
are in bytes only; the client is responsible for breaking up
into buffers on byte boundaries
NETBLT has been designed and should be implemented to work
buffers of arbitrary size. The only fundamental limitation on
size should be the amount of memory available to the client.
should be as large as possible since this minimizes the number
buffer transmissions and therefore improves performance
NETBLT is designed to require a minimum of its own memory,
the client to allocate as much memory as possible for buffer storage
In particular, NETBLT does not keep buffer copies for
purposes. Instead, data to be retransmitted is recopied
Clark & Lambert & Zhang [Page 2]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
from the client buffer. This does mean that the client
release buffer storage piece by piece as the buffer is sent, but
has not proved a problem in preliminary NETBLT implementations
Buffers are broken down by the NETBLT layer into sequences of
packets. As with the buffer size, the packet size is
between the sending and receiving NETBLTs during connection setup
Unlike buffer size, packet size is visible only to the NETBLT layer
All DATA packets save the last packet in a buffer must be the
size. Packets should be as large as possible, since in most
(including the preliminary protocol implementation) performance
directly related to packet size. At the same time, the
should not be so large as to cause Internet fragmentation, since
normally causes performance degrada- tion
All buffers save the last buffer must be the same size; obviously
last buffer can be any size required to complete the transfer.
the receiving NETBLT does not know the transfer size in advance,
needs some way of identifying the last packet in each buffer.
this reason, the last packet of every buffer is not a DATA packet
rather an LDATA packet. DATA and LDATA packets are identical
for the packet type
4. FLOW
NETBLT uses two strategies for flow control, one internal and one
the client level
The sending and receiving NETBLTs transmit data in buffers;
flow control is therefore at a buffer level. Before a buffer can
transmitted, NETBLT confirms that both clients have set up
buffers, that one is ready to send data, and that the other is
to receive data. Either client can therefore control the flow
data by not providing a new buffer. Clients cannot stop a
transfer while it is in progress
Since buffers can be quite large, there has to be another method
flow control that is used during a buffer transfer. The NETBLT
provides this form of flow control
There are several flow control problems that could arise while
buffer is being transmitted. If the sending NETBLT is
data faster than the receiving NETBLT can process it, the receiver'
ability to buffer unprocessed packets could be overflowed,
packets to be lost. Similarly, a slow gateway or
network could cause packets to collect and overflow network
Clark & Lambert & Zhang [Page 3]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
buffer space. Packets will then be lost within the network
degrading performance. This problem is particularly acute for
because NETBLT buffers will generally be quite large, and
composed of many packets
A traditional solution to packet flow control is a window system,
which the sending end is permitted to send only a certain number
packets at a time. Unfortunately, flow control using windows
to result in low throughput. Windows must be kept small in order
avoid overflowing hosts and gateways, and cannot easily be updated
since an end-to-end exchange is required for each change
To permit high throughput over a variety of networks and gateways
differing speeds, NETBLT uses a novel flow control ethod:
control. The transmission rate is negotiated by the sending
receiving NETBLTs during connection setup and after each
transmission. The sender uses timers, rather than messages from
receiver, to maintain the negotiated rate
In its simplest form, rate control specifies a minimum time
per packet transmission. This can cause performance problems
several reasons: the transmission time for a single packet is
small, frequently smaller than the granularity of the
mechanism. Also, the overhead required to maintain timing
on a per packet basis is relatively high, which degrades performance
The solution is to control the transmission rate of groups
packets, rather than single packets. The sender transmits a burst
packets over negotiated interval, then sends another burst. In
way, the overhead decreases by a factor of the burst size, and
per-burst transmission rate is large enough that timing
will work properly. The NETBLT's rate control therefore has
parts, a burst size and a burst rate, with (burst size)/(burst rate
equal to the average transmission rate per packet
The burst size and burst rate should be based not only on the
transmission and processing speed which each end can handle, but
on the capacities of those gateways and networks intermediate to
transfer. Following are some intuitive values for packet size
buffer size, burst size, and burst rate
Packet sizes can be as small as 128 bytes. Performance with
this small is almost always bad, because of the high per-
processing overhead. Even the default Internet Protocol packet
of 576 bytes is barely big enough for adequate performance.
Clark & Lambert & Zhang [Page 4]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
networks do not support packet sizes much larger than one or
thousand bytes, and packets of this size can also get fragmented
traveling over intermediate networks, degrading performance
The size of a NETBLT buffer is limited only by the amount of
available to a client. Theoretically, buffers of 100K bytes or
are possible. This would mean the transmission of 50 to 100
per buffer
The burst size and burst rate are obviously very machine dependent
There is a certain amount of transmission overhead in the sending
receiving machines associated with maintaining timers and
processes. This overhead can be minimized by sending packets
large bursts. There are also limitations imposed on the burst
by the number of available packet buffers. On most modern
systems, a burst size of between five and ten packets should
the overhead to an acceptable level. In fact, a preliminary
implementation for the IBM PC/AT sends packets in bursts of five.
could send more, but is limited by available memory
The burst rate is in part determined by the granularity of
sender's timing mechanism, and in part by the processing speed of
receiver and any intermediate gateways. It is also directly
to the burst size. Burst rates from 60 to 100 milliseconds have
tried on the preliminary NETBLT implementation with good
within a single local-area network. This value clearly depends
the network bandwidth and packet buffering available
All NETBLT flow control parameters (packet size, buffer size,
size, and burst rate) are negotiated during connection setup.
negotiation process is the same for all parameters. The
initiating the connection (the active end) proposes and sends a
of values for each parameter with its open connection request.
other client (the passive end) compares these values with
highest-performance values it can support. The passive end can
modify any of the parameters only by making them more restrictive
The modified parameters are then sent back to the active end in
response message. In addition, the burst size and burst rate can
re-negotiated after each buffer transmission to adjust the
rate according to the performance observed from transferring
previous buffer. The receiving end sends a pair of burst size
burst rate values in the OK message. The sender compares
values with the values it can support. Again, it may then modify
of the parameters only by making them more restrictive. The
parameters are then communicated to the receiver in a NULL-
packet, described later
Clark & Lambert & Zhang [Page 5]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
Obviously each of the parameters depend on many factors-- gateway
host processing speeds, available memory, timer granularity--some
which cannot be checked by either client. Each client must
try to make as best a guess as it can, tuning for performance
subsequent transfers
5.
Each NETBLT transfer has three stages, connection setup,
transfer, and connection close. Each stage must be
reliably; methods for doing this are described below
5.1. Connection
A NETBLT connection is set up by an exchange of two
between the active client and the passive client. Note
either client can send or receive data; the words "active"
"passive" are only used to differentiate the client initiating
connection process from the client responding to the
request. The first packet sent is an OPEN packet; the passive
acknowledges the OPEN packet by sending a RESPONSE packet.
these two packets have been exchanged, the transfer can begin
As discussed in the previous section, the OPEN and
packets are used to negotiate flow control parameters.
parameters used in the transfer of data are also negotiated
These parameters are (1) the maximum number of buffers that can
sending at any one time (this permits multiple buffering
higher throughput) and (2) whether or not DATA/LDATA packet
will be checksummed. NETBLT automatically checksums
non-DATA/LDATA packets. If the negotiated checksum flag is set
TRUE (1), both the header and the data of a DATA/LDATA packet
checksummed; if set to FALSE (0), only the header is checksummed
NETBLT uses the same checksumming algorithm as TCP uses
Finally, each end transmits its death-timeout value in either
OPEN or the RESPONSE packet. The death-timeout value will be
to determine the frequency with which to send KEEPALIVE
during idle periods of an opened connection (death timers
KEEPALIVE packets are described in the following section).
The active end specifies a passive client through
client-specific "well-known" 16 bit port number on which
passive end listens. The active end identifies itself through
32 bit Internet address and a 16 bit port number
In order to allow the active and passive ends to
Clark & Lambert & Zhang [Page 6]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
miscellaneous useful information, an unstructured, variable
length field is provided in OPEN and RESPONSE messages for
client-specific information that may be required
Recovery for lost OPEN and RESPONSE packets is provided by the
of timers. The active end sets a timer when it sends an
packet. When the timer expires, another OPEN packet is sent,
some pre-determined maximum number of OPEN packets have been sent
A similar scheme is used for the passive end when it sends
RESPONSE packet. When a RESPONSE packet is received by the
end, it clears its timer. The passive end's timer is
either by receipt of a GO or a DATA packet, as described in
section on data transfer
To prevent duplication of OPEN and RESPONSE packets, the
packet contains a 32 bit connection unique ID that must
returned in the RESPONSE packet. This prevents the initiator
confusing the response to the current request with the response
an earlier connection request (there can only be one
between any two ports). Any OPEN or RESPONSE packet with
destination port matching that of an open connection has
unique ID checked. A matching unique ID implies a
packet, and the packet is ignored. A non-matching unique ID
be treated as an attempt to open a second connection between
same port pair and must be rejected by sending an ABORT message
5.2. Data
The simplest model of data transfer proceeds as follows.
sending client sets up a buffer full of data. The
NETBLT sends a GO message inside a CONTROL packet to the sender
signifying that it too has set up a buffer and is ready to
data into it. Once the GO message has been received, the
transmits the buffer as a series of DATA packets followed by
LDATA packet. When the last packet in the buffer has
received, the receiver sends a RESEND message inside a
packet containing a list of packets that were not received.
sender resends these packets. This process continues until
are no missing packets, at which time the receiver sends an
message inside a CONTROL packet to the sender, sets up
buffer to receive data and sends another GO message. The sender
having received the OK message, sets up another buffer, waits
the GO message, and repeats the process
There are several obvious flaws with this scheme. First, if
LDATA packet is lost, how does the receiver know when the
has been transmitted? Second, what if the GO, OK, or
Clark & Lambert & Zhang [Page 7]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
messages are lost? The sender cannot act on a packet it has
received, so the protocol will hang. Solutions for each of
problems are presented below, and are based on two kinds
timers, a data timer and a control timer
NETBLT solves the LDATA packet loss problem by using a data
at the receiving end. When the first DATA packet in a
arrives, the receiving NETBLT sets its data timer; at the
time, it clears its control timer, described below. If the
timer expires, the receiving end assumes the buffer has
transmitted and all missing packets lost. It then sends a
message containing a list of the missing packets
NETBLT solves the second problem, that of missing OK, GO,
RESEND messages, through use of a control timer. The receiver
send one or more control messages (OK, GO, or RESEND) within
single CONTROL packet. Whenever the receiver sends a
packet, it sets a control timer (at the same time it clears
data timer, if one has been set).
The control timer is cleared as follows: Each control
includes a sequence number which starts at one and increases
one for each control message sent. The sending NETBLT checks
sequence number of every incoming control message against
other sequence numbers it has received. It stores the
sequence number below which all other received sequence
are consecutive, and returns this number in every packet
back to the receiver. The receiver is permitted to clear
control timer of every packet with a sequence number equal to
lower than the sequence number returned by the sender
Ideally, a NETBLT implementation should be able to cope
out-of-sequence messages, perhaps collecting them for
processing, or even processing them immediately. If an
control message "fills" a "hole" in a group of message
numbers, the implementation could even be clever enough to
this and adjust its outgoing sequence value accordingly
When the control timer expires, the receiving NETBLT resends
control message and resets the timer. After a
number of resends, the receiving NETBLT can assume that
sending NETBLT has died, and can reset the connection
The sending NETBLT, upon receiving a control message, should
as quickly as possible on the packet; it either sets up a
buffer (upon receipt of an OK packet for a previous buffer),
resends data (upon receipt of a RESEND packet), or sends
Clark & Lambert & Zhang [Page 8]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
(upon receipt of a GO packet). If the sending NETBLT is not in
position to send data, it sends a NULL-ACK packet, which
high-received-sequence-number as described above (this permits
receiving NETBLT to clear the control timers of any packets
are outstanding), and waits until it can send more data. In
of these cases, the overhead for a response to the
control message should be small; the total time for a response
reach the receiving NETBLT should not be much more than
network round-trip transit time, plus a variance factor
The timer system can be summarized as follows: normally,
receiving NETBLT is working under one of two types of timers,
control timer or a data timer. There is one data timer per
transmission and one control timer per control packet. The
timer is active while its buffer is being transferred; a
timer is active while it is between buffer transfers
The above system still leaves a few problems. If the
NETBLT is not ready to send, it sends a single NULL-ACK packet
clear any outstanding control timers at the receiving end.
this the receiver will wait. The sending NETBLT could die and
receiver, with all its control timers cleared, would hang. Also
the above system puts timers only on the receiving NETBLT.
sending NETBLT has no timers; if the receiving NETBLT dies,
sending NETBLT will just hang waiting for control messages
The solution to the above two problems is the use of a death
and a keepalive packet for both the sending and receiving NETBLTs
As soon as the connection is opened, each end sets a death timer
this timer is reset every time a packet is received. When
NETBLT's death timer at one end expires, it can assume the
end has died and can close the connection
It is quite possible that the sending or receiving NETBLTs
have to wait for long periods of time while their
clients get buffer space and load their buffers with data.
a NETBLT waiting for buffer space is in a perfectly valid state
the protocol must have some method for preventing the other end'
death timer from expiring. The solution is to use a
packet, which is sent repeatedly at fixed intervals when a
is waiting for buffer space. Since the death timer is
whenever a packet is received, it will never expire as long as
other end sends packets
The frequency with which KEEPALIVE packets are transmitted
computed as follows: At connection startup, each NETBLT chooses
Clark & Lambert & Zhang [Page 9]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
death-timeout value and sends it to the other end in either
OPEN or the RESPONSE packet. The other end takes
death-timeout value and uses it to compute a frequency with
to send KEEPALIVE packets. The KEEPALIVE frequency should be
enough that several KEEPALIVE packets can be lost before the
end's death timer expires
Both ends must have some way of estimating the values of the
timers, the control timers, and the data timers. The timer
obviously cannot be specified in a protocol document since
are very machine- and network-load-dependent. Instead they
be computed on a per-connection basis. The protocol has
designed to make such determination easy
The death timer value is relatively easy to estimate. Since it
continually reset, it need not be based on the transfer size
Instead, it should be based at least in part on the type
application using NETBLT. User applications should have
death timeout values to avoid forcing humans to wait long
of time for a death timeout to occur. Machine applications
have longer timeout values
The control timer must be more carefully estimated. It can
as its initial value an arbitrary number; this number can be
to send the first control packet. Subsequent control packets
have their timer values based on the network round-trip
time (i.e. the time between sending the control packet
receiving the acknowledgment of the corresponding sequence number
plus a variance factor. The timer value should be
updated, based on a smoothed average of collected round-
transit times
The data timer is dependent not on the network round-trip
time, but on the amount of time required to transfer a buffer
data. The time value can be computed from the burst rate and
number of bursts per buffer, plus a variance value <1>. During
RESENDing phase, the data timer value should be set according
the number of missing packets
The timers have been designed to permit reasonable estimation.
particular, in other protocols, determination of round-trip
has been a problem since the action performed by the other end
receipt of a particular packet can vary greatly depending on
packet type. In NETBLT, the action taken by the sender on
of a control message is by and large the same in all cases,
the round-trip delay relatively independent of the client
Clark & Lambert & Zhang [Page 10]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
Timer value estimation is extremely important, especially in
high-performance protocol like NETBLT. If the estimates are
low, the protocol makes many unneeded retransmissions,
performance. A short control timer value causes the
NETBLT to receive duplicate control messages (which it can reject
but which takes time). A short data timer value causes
receiving NETBLT to send unnecessary RESEND packets. This
considerably greater performance degradation since the
NETBLT does not merely throw away a duplicate packet, but
has to send a number of DATA packets. Because data timers are
on each buffer transfer instead of on each DATA packet transfer
we afford to use a small variance value without worrying
performance degradation
5.3. Closing the
There are three ways to close a connection: a connection close,
"quit", or an "abort".
The connection close occurs after a successful data transfer
When the sending NETBLT has received an OK packet for the
buffer in the transfer, it sends a DONE packet <2>. On receipt
the DONE packet, the receiving NETBLT can close its half of
connection. The sending NETBLT dallies for a predetermined
of time after sending the DONE packet. This allows for
possibility of the DONE packet's having been lost. If the
packet was lost, the receiving NETBLT will continue to send
final OK packet, which will cause the sending end to resend
DONE packet. After the dally period expires, the sending
closes its half of the connection
During the transfer, one client may send a QUIT packet to
other if it thinks that the other client is malfunctioning.
the QUIT occurs at a client level, the QUIT transmission can
occur between buffer transmissions. The NETBLT receiving the
packet can take no action other than to immediately notify
client and transmit a QUITACK packet. The QUIT sender must
out and retransmit until a QUITACK has been received or
predetermined number of resends have taken place. The sender
the QUITACK dallies in the manner described above
An ABORT takes place when a NETBLT layer thinks that it or
opposite is malfunctioning. Since the ABORT originates in
NETBLT layer, it can be sent at any time. Since the ABORT
that the NETBLT layer is malfunctioning, no transmit
is expected, and the sender can immediately close it connection
Clark & Lambert & Zhang [Page 11]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
6. MULTIPLE
In order to increase performance, NETBLT has been designed in
manner that encourages a multiple buffering implementation.
buffering is a technique in which the sender and receiver
and transmit buffers in a manner that allows error recovery
previous buffers to be concurrent with transmission of
buffer
During the connection setup phase, one of the negotiated
is the number of concurrent buffers permitted during the transfer
The simplest transfer allows for a maximum of one buffer to
transmitted at a time; this is effectively a lock-step protocol
causes time to be wasted while the sending NETBLT receives
to send a new buffer. If there are more than one buffer available
transfer of the next buffer may start right after the current
finishes. For example, assume buffer A and B are allowed to
concurrently, with A preceding B. As soon as A finishes
its data and is waiting for either an OK or a RESEND message, B
start sending immediately, keeping data flowing at a stable rate.
A receives an OK, it is done; if it receives a RESEND, the
packets specified in the RESEND message are retransmitted.
packets flow out through a priority pipe, with the priority equal
the buffer number, and with the transfer rate specified by the
size and burst rate. Since buffer numbers increase monotonically
packets from an earlier buffer in the pipe will always precede
of the later ones. One necessary change to the timing algorithm
that when the receiving NETBLT set data timer for a new buffer,
timer value should also take into consideration of the transfer
for all missing packets from the previous buffers
Having several buffers transmitting concurrently is actually not
much more complicated than transmitting a single buffer at a time
The key is to visualize each buffer as a finite state machine
several buffers are merely a group of finite state machines, each
one of several states. The transfer process consists of
buffers through various states until the entire transmission
completed
The state sequence of a send-receive buffer pair is as follows:
sending and receiving buffers are created independently.
receiving NETBLT sends a GO message, putting its buffer in
"receiving" state, and sets its control timer; the sending
receives the GO message, putting its buffer into a "sending" state
The sending NETBLT sends data until the buffer has been transmitted
If the receiving NETBLT's data timer goes off before it received
last (LDATA) packet, or it receives the LDATA packet in the
Clark & Lambert & Zhang [Page 12]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
and packets are missing, it sends a RESEND packet and moves
buffer into a "resending" state. Once all DATA packets in the
and the LDATA packet have been received, the receiving NETBLT
its buffer into a "received" state and sends an OK packet.
sending NETBLT receives the OK packet and puts its buffer into
"sent" state
7. PROTOCOL LAYERING
NETBLT is implemented directly on top of the Internet Protocol (IP).
It has been assigned a temporary protocol number of 255. This
will change as soon as the final protocol specification has
determined
8. PACKET
NETBLT packets are divided into three categories, each of which
a common packet header. First, there are those packets that
only from sender to receiver; these contain the control
sequence numbers which the receiver uses for reliability.
packets are the NULL-ACK, DATA, and LDATA packets. Second, there
a packet that travels only from receiver to sender. This is
CONTROL packet; each CONTROL packet can contain an arbitrary
of control messages (GO, OK, or RESEND), each with its own
number. Finally, there are those packets which either have
ways of insuring reliability, or are not reliably transmitted.
are the QUIT, QUITACK, DONE, KEEPALIVE, and ABORT packets. Of these
all save the DONE packet can be sent by both sending and
NETBLTs
Packet type numbers
OPEN: 0
RESPONSE: 1
KEEPALIVE: 2
DONE: 3
QUIT: 4
QUITACK: 5
ABORT: 6
DATA: 7
LDATA: 8
NULL-ACK: 9
CONTROL: 10
Clark & Lambert & Zhang [Page 13]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
Standard header
local port: 2
foreign port: 2
checksum: 2
version number: 1
packet type: 1
packet length: 2
OPEN and RESPONSE packets
connection unique ID: 4
standard buffer size: 4
transfer size: 4
DATA packet data segment size: 2
burst size: 2
burst rate: 2
death timeout value in seconds: 2
transfer mode (1 = SEND, 0 = RECEIVE): 1
maximum number of concurrent buffers: 1
checksum entire DATA packet /
DATA packet data only (1/0): 1
client-specific data:
DONE, QUITACK, KEEPALIVE
standard header
ABORT, QUIT
reason: arbitrary
CONTROL packet format
CONTROL packets consist of a standard NETBLT header of
CONTROL, followed by an arbitrary number of control messages
the following formats
Control message numbers
GO: 0
OK: 1
RESEND: 2
Clark & Lambert & Zhang [Page 14]
RFC 969 December 1985
NETBLT: A Bulk Data Transfer
OK message
message type (OK): 1
buffer number: 4
sequence number: 2
new burst size: 2
new burst interval: 2
GO message
message type (GO): 1
buffer number: 4
sequence number: 2
RESEND message
message type (RESEND): 1
buffer number: 4
sequence number: 2
number of missing packets: 2
packet numbers...: n * 2
DATA, LDATA packet formats
buffer number: 4
highest consecutive sequence number received: 2
packet number within buffer: 2
data: arbitrary
NULL-ACK packet format
highest consecutive sequence number received: 2
acknowledged new burst size: 2
acknowledged new burst interval: 2
NOTES
<1> When the buffer size is large, the variances in the round
delays of many packets may cancel each other out; this means
variance value need not be very big. This expectation can
verified in further testing
<2> Since the receiving end may not know the transfer size
advance, it is possible that it may have allocated buffer
and sent GO messages for buffers beyond the actual last
sent by the sending end. Care must be taken on the
end's part to ignore these extra GO messages
Clark & Lambert & Zhang [Page 15]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
