This topic describes the daemon message types that the configuration daemon server's ServiceL() function handles.
The server must handle 5 message types in its session ServiceL() function. These message types are as follows:
The Configuration message type allows the daemon to configure the interface as it starts up. For more information see Configuration.
The deregistration message type allows the daemon to take action when the interface is shutting down. For more information see Deregistration.
Progress notifications allow the daemon to notify clients of events. For more information see Progress notifications.
Ioctl commands allow the daemon to handle daemon-specific requests from clients. For more information see Ioctl commands.
Cancellation and Cancellation mask messages allow asynchronous requests to the daemon to be cancelled. For more information see Cancellation
When a new connection is requested, the server receives an EConfigDaemonConfigure message. It occurs when a NIF calls MNifIfNotify::LinkLayerUp() to indicate to NIFMAN that the link layer is up.
TConnectionInfoBuf packages a TConnectionInfo object that specifies the IDs of CommDb IAP and Network records used for the connection.
The message has a data buffer parameter that provides a TConnectionInfoBuf object.
The following code reads the CommDb IAP ID from a received message:
TConnectionInfoBuf conInfoBuf; aMessage.Read(0, conInfoBuf); TConnectionInfo conInfo = conInfoBuf(); TInt iap = conInfo.iIapId;
This information allows the daemon to access the relevant CommDb records, and to update the fields. A Mobile IP daemon obtains a care-of-address for the phone and set the IP address for the interface using RSocket::SetOpt(KSoInetConfigInterface, KSolInetIfCtrl, interfaceInfoBuf).
The message request is asynchronous, and can be cancelled with a EConfigDaemonCancel or EConfigDaemonCancelMask request.
If the configuration is slow or if the idle timeouts are short, the daemon configuration may be interrupted by the expiry of the NIFMAN idle timer. To overcome this, the configuration daemon can disable and then enable idle timers at appropriate times using RConnection::SetOpt(KCOLProvider, KConnDisableTimers, ETrue).
Note: NIFMAN waits indefinitely for a configuration daemon to finish configuration of the interface if the idle timers have been disabled. The configuration daemon must be implemented robustly to ensure that the request is always terminated.
The server receives a EConfigDaemonDeregister message when an interface is shuts down for one of the following reasons:
The NIFMAN idle timer is expired. This timer shuts down the interface if there has not been activity for a specified time. For more information about the time out values, see Reference
RConnection::Stop() is called on the interface.
When it receives a deregistration message, the configuration daemon instructs NIFMAN to go into fast dormant mode. NIFMAN then keeps the NIF and the agent loaded, and stops the idle timer.
When the daemon instructs NIFMAN to go into fast dormant mode, the daemon tells NIFMAN when the link is up again. It does this by issuing a KConfigDaemonFinishedDormantMode progress notification. For more information about progress notifications, see progress notifications. NIFMAN sets the link state to indicate that it is up, and restarts the idle timer.
The deregistration message has two parameters:
0: an integer in parameter that identifies the cause of the deregistration request.
This is an enum EConfigDaemonDeregisterCause value, being either EConfigDaemonDeregisterCauseTimer, meaning the deregistration was caused by the NIFMAN idle timer, or EConfigDaemonDeregisterCauseStop which means the deregistration was caused by RConnection::Stop().
1: a TDes8* out parameter that identifies the action NIFMAN must take.
The daemon should package into this output buffer an enum EConfigDaemonDeregisterAction value. The defined values are EConfigDaemonDeregisterActionStop, meaning to stop the interface, or EConfigDaemonDeregisterActionPreserve, meaning to preserve the interface state.
The message request is asynchronous, and can be cancelled with an EConfigDaemonCancel or EConfigDaemonCancelMask request. For more information see Cancellation.
Deregistration can be interrupted when the NIFMAN idle timer expires. For more information see Configuration.
When running, a daemon can generate progress notifications at any time. The NifMan receives these notifications and pass them to ESock and all ESock clients that subscribe to RConnection::ProgressNotification() for the current interface.
When the daemon is loaded it receives an EConfigDaemonProgress message that requests progress notifications. The message has a single out parameter, a TDaemonProgressBuf, which packages a TDaemonProgress object. This has integer fields to hold the progress stage and error code. The integer fields correspond to those in the TNifProgress object. The client receives the TNifProgress object from RConnection::ProgressNotification(). To send a notification from the client, the daemon writes its progress information into this parameter and complete this message. NifMan handles the notification and issues a progress request to the daemon.
The daemon can define the appropriate stages for the function. KConfigDaemonFinishedDormantMode is used when resuming the link from dormant mode.
When a client issues a RConnection::Ioctl() call the server receives an EConfigDaemonIoctl message. The configuration daemon can define its own set of ioctl commands, appropriate to its function.
The following 4 parameters can be used:
0: an integer specifying the ioctl option level
1: an integer specifying the ioctl option name
2: a pointer to a caller supplied data buffer (TDes8*). This is optional. If set, the message handler reads data from the buffer, and writes back to it to return data to the caller.
3: an integer specifying the maximum length of the caller supplied data buffer. If a buffer is not supplied this has a value of 0.
The following code gets the option level and name from the message. For messages that supply a data buffer (length>0) the code calls a handler function HandleClientRequestL(). HandleClientRequestL() includes the returned buffer in the message.
TUint optionLevel = aMessage.Int0(); TUint optionName = aMessage.Int1(); TInt length = aMessage.Int3(); if (length>0) { HBufC8* buffer = HBufC8::NewMaxLC(length); TPtr8 ptr = buffer->Des(); aMessage.ReadL(2, ptr); HandleClientRequestL(optionLevel, optionName, &ptr); aMessage.Write(2, ptr); CleanupStack::PopAndDestroy(buffer); aMessage.Complete(KErrNone); }
The message request is asynchronous, and can be cancelled with an EConfigDaemonCancel or EConfigDaemonCancelMask request.
An EConfigDaemonCancel message cancels all outstanding requests except progress notifications. It does not have parameters. The service function completes the message and cancels any current asynchronous operations.
An EConfigDaemonCancelMask message has a single integer parameter. If the parameter is KConfigDaemonOpMaskProgress the progress notifications are cancelled. If the parameter is KConfigDaemonOpMaskGeneral, all other outstanding operations are cancelled. KConfigDaemonOpMaskGeneral provides the same functionality as EConfigDaemonCancel.