XinStellaris commented on code in PR #1312:
URL:
https://github.com/apache/incubator-nuttx-apps/pull/1312#discussion_r964759730
##########
netutils/dhcpc/dhcpc.c:
##########
@@ -720,13 +724,18 @@ int dhcpc_request(FAR void *handle, FAR struct
dhcpc_state *presult)
/* Send the DISCOVER command */
- ninfo("Broadcast DISCOVER\n");
- if (dhcpc_sendmsg(pdhcpc, presult, DHCPDISCOVER) < 0)
+ if (last_send == 0 ||
Review Comment:
According to RFC2131: "DHCP clients are responsible for all message
retransmission. The
client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between
the client and the server. "
It is better to let dhcp send delay be different from recv time out. So I
think recv time out shouldn't be related to send delay. That is the reason why
I put a last_send here.
In the future we might need to add an exponential backoff algorithm here
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
