RFC relevance of acknowledgment

As per Relevance of the word acknowledgment, we have this rfc below:

Network Working Group A.
Request for Comments: 2090 Lanworks Technologies Inc
Category: Experimental February 1997

TFTP Multicast

Status of this

This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

The Trivial File Transfer Protocol [1] is a simple, lock-step,
transfer protocol which allows a client to get or put a file onto
remote host

This document describes a new TFTP option. This new option will
the multiple clients to receive the same file concurrently
the use of Multicast packets. The TFTP Option Extension mechanism
described in [2].

Often when similar computers are booting remotely they will
download the same image file. By adding multicast into the
option set, two or more computers can download a
concurrently, thus increasing network efficiency

This document assumes that the reader is familiar with
terminology and notation of both [1] and [2].

Multicast Option

The TFTP Read Request packet is modified to include the
option as follows

+--------+----~~----+---+--~~--+---+-----------+---+---+
| opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
+--------+----~~----+---+--~~--+---+-----------+---+---+

The opcode field contains a 1, for Read Requests, as
in [1].

Emberson Experimental [Page 1]

RFC 2090 TFTP Multicast Option February 1997

The name of the file to be read, as defined in [1]. This is
NULL-terminated field

The mode of the file transfer: "netascii", "octet",
"mail", as defined in [1]. This is a NULL-terminated field

Request for multicast transmission of the file option
"multicast" (case insensitive). This is a NULL-
field. The value for this option request is a string of
length

If the server is willing to accept the multicast option,
sends an Option Acknowledgment (OACK) to the client
the multicast option, as defined in [2]. The OACK to the
will specify the multicast address and flag to indicate
that client should send block acknowledgments (ACK).

+-------+-----------+---+-------~~-------+---+
| opc | multicast | 0 | addr, port, mc | 0 |
+-------+-----------+---+-------~~-------+---+

The opcode field contains the number 6, for
Acknowledgment, as defined in [2].

Acknowledges the multicast option. This is a NULL-
field

The addr field contains the multicast IP address. This
is terminated with a comma

The port field contains the destination port of the
packets. The use of Registered Port number 1758 (tftp-mcast
is recommended. This field is terminated with a comma

This field will be either 0 or 1, to tell the client
it is the master client, that is, it is responsible
sending ACKs to the server. This is NULL-terminated field

Emberson Experimental [Page 2]

RFC 2090 TFTP Multicast Option February 1997

Data

After the OACK is received by the client it will send an ACK
packet zero, as in [2]. With the multicast option being accepted
ACK will indicate to the server that the client wants the
packet. In other words the ACKs may now be seen as a request for
n+1th block of data. This enables each a client to request any
within the file that it may be missing

To manage the data transfer the server will maintain a list
clients. Typically the oldest client on the list, from here
referred to as the Master Client, will be responsible for
ACKs. When the master client is finished, the server will
another OACK to the next oldest client, telling it to start
ACKs. Upon receipt of this OACK the new master client will send
ACK for the block immediately before the first block required
complete its download

Any subsequent clients can start receiving blocks of a file during
transfer and then request any missing blocks when that client
the master client. When the current master client is finished,
server will notify the next client with an OACK making it the
master client. The new master client can start requesting
packets. Each client must terminate the transfer by sending
acknowledgment of the last packet or by sending an error message
server. This termination can occur even if the client is not
master client

Any subsequent OACKs to a client may have an empty multicast
and port fields, since this information will already be held by
client. In the event a client fails to respond in a timely manner
a OACK enabling it as the master client, the server shall select
next oldest client to be the master client. The server
reattempt to send a OACK to the non- responding client when the
master client is finished. The server may cease communication with
client after a reasonable number of attempts

Each transfer will be given a multicast address for use to
the data packets. Since there can be multiple servers on a
network or a limited number of addresses available to a given server
it is possible that their might be more than one transfer using
multicast address. To ensure that a client only accepts the
packets, each transfer must use a unique port on the server.
source IP address and port number will identify the data packets
the transfer. Thus the server must send the unicast OACK packet
the client using the same port as will be used for sending
multicast data packets

Emberson Experimental [Page 3]

RFC 2090 TFTP Multicast Option February 1997

At any point if a client, other than the master client, sends a
to the server, the server will respond with another OACK with the
field holding a value of zero. If this client persists in
erroneous ACKs, the server may send an error packet to the client
discontinuing the file transfer for that client

The server may also send unicast packets to a lone client to
adverse effects on other machines. As it is possible that
may be forced to process many extraneous multicast packets
attempting to receive a single multicast address

clients server
------------------------------------------------------------
1 C1 |1|afile|0|octet|0|multicast|0|0| ->
2 C1 <- |6|multicast|224.100.100.100,1758,1|
3 C1 |4|0| ->
4 M <- |3|1|1| 512 octets of data|
5 C1 |4|1| ->
6 M <- |3|2|1| 512 octets of data|
7 C2 |1|afile|0|octet|0|multicast|0|0| ->
8 C2 <- |6|multicast|224.100.100.100,1758,0|
9 C2 |4|0| ->
10 C1 |4|2| ->
11 M <- |3|3|1| 512 octets of data|
12 C3 |1|afile|0|octet|0|multicast|0|0| ->
13 C3 <- |6|multicast|224.100.100.100,1758,0|
14 C1 |4|3| ->
15 C2 |4|0| ->
16 M (except C2) <- |3|4|1| 512 octets of data|
17 C1 |4|4| ->
18 M <- |3|5|1| 512 octets of data|
19 C1 |4|5| ->
20 M <- |3|6|1| 100 octets of data|
21 C1 |4|6| ->
22 C2 <- |6|multicast|,,1|
23 C2 |4|0| ->
24 M <- |3|1|1| 512 octets of data|
25 C2 |4|1| ->
26 M <- |3|2|1| 512 octets of data|
27 C2 |4|3| ->
28 M <- |3|4|1| 512 octets of data|
29 C2 |4|6| ->
30 C3 <- |6|multicast|,,1|
31 C3 |4|2| ->
32 M <- |3|3|1| 512 octets of data|
33 C3 |4|6| ->

Emberson Experimental [Page 4]

RFC 2090 TFTP Multicast Option February 1997

Comments
1 request from client 1
2 option
3 acknowledgment for option acknowledgment
or request for first block of
4 first data packet sent to the multicast
7 request from client 2
8 option acknowledgment to client 2,
send no
9 OACK acknowledgment from client 2
15 OACK acknowledgment from client 3
16 client 2 fails to receive a
21 client 1 acknowledges receipt of the last block
telling the server it is
23 option acknowledgment to client 2,
now the master
25 client 2 acknowledging with request for first
27 client 2 acknowledges with request for missed
29 client 2 signals it is
31 client 3 is master client and asks for missing
33 client 3 signals it is

With the use of the multicast and blocksize[3] options TFTP will
capable of fast and efficient downloads of data. Using TFTP with
multicast option will maintain backward compatibility for
clients and servers

Security

Security issues are not discussed in this memo

[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
1350, MIT, July 1992.

[2] Malkin, G., and A. Harkin, "TFTP Option Extension",
1782, Xylogics, Inc., Hewlett Packard Co., March 1995.

[3] Malkin, G., and A. Harkin, "TFTP Blocksize Option",
1783, Xylogics, Inc., Hewlett Packard Co., March 1995.

Emberson Experimental [Page 5]

RFC 2090 TFTP Multicast Option February 1997

Author's

A. Thomas
Lanworks Technologies, Inc
2425 Skymark
Mississauga,
Canada L4W 4Y

Phone: (905) 238-5528
EMail: tom@lanworks.

Emberson Experimental [Page 6]

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