This API publishes a routine to maintain DHCP state, and a
semaphore that is signalled when a lease requires attention: this
is your clue to call the aforementioned routine.
The intent with this API is that a simple DHCP client thread,
which maintains the state of the interfaces, can go as follows:
(after init_all_network_interfaces() is
called from elsewhere)
while ( 1 ) {
while ( 1 ) {
cyg_semaphore_wait( &dhcp_needs_attention );
if ( ! dhcp_bind() ) // a lease expired
break; // If we need to re-bind
}
dhcp_halt(); // tear everything down
init_all_network_interfaces(); // re-initialize
} |
and if the application does not want to suffer the overhead
of a separate thread and its stack for this, this functionality
can be placed in the app’s server loop in an obvious fashion.
That is the goal of breaking out these internal elements. For example,
some server might be arranged to poll DHCP from time to time like
this:
while ( 1 ) {
init_all_network_interfaces();
open-my-listen-sockets();
while ( 1 ) {
serve-one-request();
// sleeps if no connections, but not forever;
// so this loop is polled a few times a minute...
if ( cyg_semaphore_trywait( &dhcp_needs_attention )) {
if ( ! dhcp_bind() ) {
close-my-listen-sockets();
dhcp_halt();
break;
}
}
}
} |
If the configuration option CYGOPT_NET_DHCP_DHCP_THREAD
is defined, then eCos provides a thread as described initially.
Independent of this option, initialization of the interfaces still
occurs in init_all_network_interfaces() and
your startup code can call that. It will start the DHCP management
thread if configured. If a lease fails to be renewed, the management
thread will shut down all interfaces and attempt to initialize all
the interfaces again from scratch. This may cause chaos in the
app, which is why managing the DHCP state in an application aware
thread is actually better, just far less convenient for testing.