Symbian OS Communications (779884), страница 37
Текст из файла (страница 37)
The GN role allows the phone to act asan Ethernet switch to connect other Bluetooth PAN devices togetherto create an ad-hoc network. The PANU role allows the device toconnect to other Bluetooth PAN devices, and also to network accesspoints to use external IP networks.• Ethernet-based technologies such as wireless LAN. However not alldevices provide WLAN support so check with the device manufacturers for a list of their WLAN-enabled devices.Note: many existing IP-based applications on mobile phones aredesigned to use GPRS. Code examples in this chapter will also useGPRS, with an indication given where other technologies function orperform differently.Note that Bluetooth PAN profile support is not available in S60 3rdedition devices.Symbian OS makes connecting to different types of network as transparent as possible.
However, the application developer should rememberthat different technologies have different performance characteristics, anda application that works well over WLAN may perform poorly over GPRSor a slower connection. This chapter will address how applications canmake themselves robust to different network characteristics that may notbe encountered on a device with a fixed network connection. Particularproblems encountered on mobile devices include:• Out of coverage – a network may be temporarily unavailable dueto geographical conditions. Sometimes coverage can fluctuate overa matter of minutes, so this condition can range from being verytransient to being more permanent (e.g., a number of hours, orpossibly days).• Limited resources – a network may be unavailable because the maximum number of connections already exists. Some examples of thisare network operators supporting a maximum number of active PDPcontexts per device, or if a WLAN connection is already active on thedevice, and the app wishes to connect to a different WLAN.NETWORK BEARER TECHNOLOGIES IN SYMBIAN OS165• Network busy – the network has no resources available to supportmore users.• Service unavailable – whilst the network may be available and issupported by the device, a service may be unavailable at certaintimes, for example, when roaming, or due to lack of credit or nosubscription.• The time taken to make the network connection, particularly if userinteraction is required.The next section explains how to use the networking APIs to configure,connect and use IP networks.
This can be briefly summarized as follows:1. Configure – ensure the connection parameters are configured.2. Connect – ensure the correct connection type and parameters areused.3. Use – send and receive data via sockets.4. Disconnect – indicate that you have finished with the connection.6.3.1 Connecting to an IP NetworkApplications wishing to create and use a IP network connection must havethe NetworkServices capability. RConnection is used to connect toa specific IP network via an IAP as follows.First, create a server connection to the sockets server:RSocketServ iSockServ;// this should be a member variable// of a class...TInt err = iSockServ.Connect();As with all client/server connections, the error must be checked anderrors handled.Next, use this to open the RConnection object:RConnection iConn;// this should be a member variable// of a class...err = iConn.Open(iSockServ);Programmatically, there are at least three different ways to start anetwork connection, depending on your application’s needs.
Each ofthese may cause different user visible behavior, such as triggering aprompt asking which connection to use.166IP AND RELATED TECHNOLOGIESWithout using RConnectionApplications can use sockets directly without having first explicitly startedthe network connection. When IP traffic is sent, the network connectionwill automatically be brought up. The user may be prompted to selectwhich IAP is used in this case – this happens for most built-in applicationson S60 devices but the user can override this behavior on UIQ and usethe default (a.k.a. implicit or ‘preferred’) IAP.The disadvantage of not using RConnection is that you have no wayof tracking the status of the connection, so it is harder to determine if orwhy the connection has failed – errors returned from socket operationswill provide an indication, but only some time later. Also, creation ofa network connection may take a potentially large number of seconds,or on occasions a number of minutes, to succeed or fail (particularly ifuser input is required) so the application may try to send data before theconnection has been fully established.
This can cause unreliable data tobe lost while the network connection is established – if this is importantthe KSoUdpSynchronousSend Ioctl can be used, as described later inthe chapter.Using RConnection::Start() with no parametersiConn.Start(iStatus);In terms of selecting which IAP to start this is similar to not usingan RConnection; however it gives the application more control andvisibility of the connection as it is established – the request completeswhen the connection succeeds or fails and the application can alsouse the same RConnection to track the progress of the connectionas described later. Because no connection parameters are given, it hasthe same user visible results as not using RConnection at all, i.e. theuser may be prompted to select which IAP to use, or the default IAPwill be used. If the connection fails, the error is returned asynchronouslyvia the TRequestStatus.
Again because the creation of the networkconnection may take a number of seconds the use of the asynchronousversion of this API is recommended.Using RConnection::Start() with an explicit IAPTo connect to a particular network, the application must provide an IAP IDin its call to RConnection::Start().
To do this, the application mustfirst determine which IAP to use – this may already be configured by theuser in the application’s own UI, or the application may use the CommsDat APIs to search for the most appropriate IAP of all those configuredbased on some application specific criteria. Either way, the applicationNETWORK BEARER TECHNOLOGIES IN SYMBIAN OS167will need to be able to retrieve IAP information from CommsDat. This isdescribed in section 6.3.2.6.3.2 Choosing the Connection ParametersIt is important to make sure that the correct connection parameters areused or the application may fail to work, the user may be over charged orprivate data may be sent over a public network. On a Symbian OS baseddevice there are several networks available, potentially simultaneously.
Itshould not be assumed that any network connection is suitable, especiallyas some network connections, such as the one to the operator’s MMSnetwork, are only suitable for a limited number of services – in this case,just the MMS service.Connection configuration parameters are stored in CommsDat.Previous versions of Symbian OS used CommDB; and the CCommsDatabase APIs are provided in order to support older applicationsand ease porting, but will be deprecated in future versions of SymbianOS.
New applications should use the CommsDat APIs directly so onlythese are discussed.Most devices are preconfigured with a set of parameters for connectingto the network operator’s services, and also possibly for using BT PANand WLAN for ad-hoc connections. Each application may need to usea different set of criteria for determining which IAP to use (e.g. userselected, based on bearer type etc.) but is likely to need to extract therelevant information about the currently configured IAPs from CommsDatto display to the user, and to use when starting the connection.Figure 6.4 shows a simplified view of how the settings are stored inCommsDat.
The full set of parameters is described in more detail in theSymbian OS Library, and is programmatically described in CommsDatTypesV1_1.h.The main table of interest is the IAP table – this contains the name ofthe IAP, as you would expect to see it in the device’s UI, and links to theappropriate service and bearer tables for that IAP.The per-technology service tables contain settings that vary betweendifferent services of a particular type – for example, the APN for a GPRSconnection, the phone number for a CSD connection or an SSID for aWLAN connection, as well as the usernames and passwords for the service, and the IP addressing configuration (static, dynamically negotiatedduring connection, via DHCP, etc).The per-technology bearer tables contain information that is fixedfor accessing a particular type of service and often relates to the use ofparticular hardware – for example, the AT commands to send to a modem;168IP AND RELATED TECHNOLOGIESIAP tableName (for display)TypeLink for service tableService tablesDial out ISP tableOutgoing GPRS tablePhone numberUsernamePasswordIP address config.DNS server config.APNUsernamePasswordAuthenticationIP address config.DNS server config.LAN tableIP address config.DNS server config.Figure 6.4 Connection parameters and IAPs stored in CommsDatthe NIF and agent name to use with a particular bearer; information on thehardware resources a connection should use, such as serial ports; andthe values for the various modes of the idle timer, the purpose of whichis explained further in section 6.3.4.So for the application, the first thing to do is to create the CommsDatdatabase session:using namespace CommsDat;CMDBSession* dbs = CMDBSession::NewLC(KCDVersion1_1);Entries in CommsDat are accessed using record sets –CMDBRecordSet – of a given type.
For the IAP table, this type is theCCDIAPRecord, identified by the KCDTIdIAPRecord record type ID.So to create and load a record set for the IAP table:CMDBRecordSet<CCDIAPRecord> * iapTable = new (ELeave)CMDBRecordSet<CCDIAPRecord>(KCDTIdIAPRecord);CleanupStack::PushL(iapTable);// Load the table into memoryTRAPD(r, iapTable->LoadL(*dbs));Errors here could mean that the IAP table doesn’t exist, i.e. that thereare no IAPs configured. Applications should ensure that the user hasconfigured an appropriate IAP.Once the table is loaded, the iRecords member of the record set,an RPointerArray, can be used to iterate through the records in thetable.
Each member of the array is stored as a CMDBRecordBase* soNETWORK BEARER TECHNOLOGIES IN SYMBIAN OS169the returned object needs to be cast to its correct type, in this casea CCDIAPRecord. The process by which the application determineswhich IAP to use is up to the application – the example below extractsthe name and type of the IAP for displaying to a user, and then stores thechosen IAP ID for use later. The full set of information available about anIAP is found in CommsDatTypesV1_1.h.No platform security capabilities are required to read most entries fromCommsDat, apart from fields considered sensitive, such as passwords,which typically require ReadUserData; or device sensitive data, whichrequires ReadDeviceData.TInt numIaps = iapTable->iRecords.Count();TInt chosenIAP = KErrNotFound;for(TInt i = 0; i<numIaps; i++){CCDIAPRecord* iap = static_cast<CCDIAPRecord*>(iapTable->iRecords[i]);chosenIAP = iap->RecordId();if(iap->iBearerType.GetL().Compare(KCDTypeNameLANBearer==0){TBuf<KMaxMedTextLength> buf(iap->iRecordName.GetL());// Add to buffer for display of ID and Name to user...// This is the one we wantbreak;}}This example iterates through all records looking for one’s thatuse the LANBearer table for demonstration purposes, but there is amore efficient way to do this – using FindL().
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
