Un inconveniente a la simplicidad de usar UDP para los mensajes BOOTP es que no obtenemos características de transporte de calidad. UDP es poco fiable, una solicitud BOOTP podría perderse antes de llegar al servidor, en forma similar la respuesta del servidor podría no regresar al cliente. Como muchos otros protocolos que usan UDP, los clientes BOOTP cuidan esto usando un temporizador de retransmisión. Si luego de cierto periodo de tiempo el cliente no ha recibido una respuesta, reenvía la solicitud.
Sin embargo, los clientes BOOTP deben tener cuidado sobre como implementar su estrategia de retransmisión. Considere un escenario donde una red con 200 clientes BOOTP pierde el suministro eléctrico. Estas maquinas son muy similares, entonces cuando regresa la electricidad todas se reinician e intentan enviar solicitudes BOOTP casi al mismo tiempo. Más probablemente, ocurrirán problemas debido a todas estas solicitudes; algunas se perderán y otras serán abandonadas debido a la sobrecarga.
Si todos los clientes usan el mismo tiempo para la retransmisión, cuando ese tiempo culmine un montón de computadoras enviarán nuevamente solicitudes y se recreará el problema original. Para evitar esto, el estándar BOOTP recomienda usar un esquema backoff exponencial para la retransmisiones, empezando con un intervalo de 4 segundos y duplicándolo en los intentos sucesivos. Un elemento aleatorio también debe ser sumado o restado para prevenir que coincidan las retransmisiones de demasiados dispositivos. De esta manera reducimos las chances de perder retransmisiones y nos aseguramos de que el tráfico BOOTP no atasque la red.
No hay comentarios:
Publicar un comentario