Connected: An Internet Encyclopedia
RFC 951 - 7.2. Client Retransmission Strategy

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 951
Up: 7. Packet Processing
Prev: 7.1. Client Transmission
Next: 7.3. Server Receives BOOTREQUEST

### 7.2. Client Retransmission Strategy

If no reply is received for a certain length of time, the client should retransmit the request. The time interval must be chosen carefully so as not to flood the network. Consider the case of a cable containing 100 machines that are just coming up after a power failure. Simply retransmitting the request every four seconds will inundate the net.

As a possible strategy, you might consider backing off exponentially, similar to the way ethernet backs off on a collision. So for example if the first packet is at time 0:00, the second would be at :04, then :08, then :16, then :32, then :64. You should also randomize each time; this would be done similar to the ethernet specification by starting with a mask and 'and'ing that with with a random number to get the first backoff. On each succeeding backoff, the mask is increased in length by one bit. This doubles the average delay on each backoff.

After the 'average' backoff reaches about 60 seconds, it should be increased no further, but still randomized.

Before each retransmission, the client should update the 'secs' field. [UDP checksum.]

Next: 7.3. Server Receives BOOTREQUEST

Connected: An Internet Encyclopedia
RFC 951 - 7.2. Client Retransmission Strategy