Networking

DCI driver link status change

Under the DCI, network device drivers must announce their presence through Service_DCIDriverStatus (&9D). It is assumed that devices announcing themselves in this way are available for use. The device may become unavailable, most likely due to link loss (such as a cable being disconnected) or memory shortage. No indication is available to the user as to the state of the device from the driver.

In order to allow notifications of such states to be provided to the user (and to other clients who may need to be aware of network infrastructure changes), it is proposed that the service call be extended. Authors should consult the DCI driver specification or the Internet chapter within PRM 5a for more details of the current interface. In summary, Service_DCIDriverStatus is issued by drivers to announce startup (reason 0) and shutdown (reason 1) of a driver and its associated DIB (Device Information Block).

This has been extended to include announcement of link status changes. Two new reason codes are to be used for this purpose.

On entry

   R0 = pointer to driver information block
   R1 = &9D (service number)
   R2 = reason code
         0 = Device driver starting (as previously)
         1 = Device driver terminating (as previously)
         2 = Device driver link active
         3 = Device driver link inactive
   R3 = DCI version supported (as previously)

On exit

   All registers preserved

This service is issued to announce changes to a Device Driver. An 'active link' indicates that the device driver is capable of sending and receiving data. An 'inactive link' will never send or receive data. This mirrors the use of the DCI statistics flag. For compatibility with devices which are not aware of these new reason codes, all modules should assume that a newly started device driver have an active link. It follows that any device which starts up and is aware of these new reason codes must issue the 'link inactive' (reason code 3) service if its link is not available.

Expected uses for this service :

Dynamic address configuration in presence of new network infrastructure (eg ZeroConf address re-announcement, DHCP lease renewal)

User notification of network absence (eg Notifier protocol)

Non-module clients, and module clients wishing to obtain more information about the state of the link should query the statistics for the DCI driver in the usual manner.

Drivers may, but are not required to, defer announcement of inactive links if their physical state is such that transient failures (in the order of seconds) may occur. Drivers which can detect the physical nature of the network to which they are connected must signal a link state change when they detect such a change (eg configuration changes to a wireless network SSID, encryption key, channel, etc).

Clients should expect that any 'link inactive' notification may indicate that the previous network connection is invalid. On 'link active' notification, clients may attempt to re-establish connections to remote systems.

Clients should attempt to use the existing connections before restarting a lengthy negotiation or configuration process. Where confidential information is involved, clients should not attempt to re-establish any connection without first confirming the action with the user.

This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.

HTML document version 1.03 3rd November 2015