Symbian OS Communications (779884), страница 43
Текст из файла (страница 43)
Note that in some cases you may see the selection stagesrepeated many times if the system is trying alternate connections (forexample, if the first connection cannot be made and the system movesto the second connection preference).• KLinkLayerOpen – the connection has been successfully activatedand, in most cases, an IP address has been allocated. This is the firststage where it is possible to send IP traffic. Situations where this stageis reached and an IP address might not have been allocated mainlyinvolve DHCP over Ethernet, or Ethernet-like, networks.• KDataTransferTemporarilyBlocked – data transfer on the connection is temporarily disabled.
The reasons for this will be dependenton the bearer, but this could happen if, for example, a GPRS contextis suspended because the user temporarily moves out of networkcoverage. Not all GPRS connections will send this progress stage,as it depends on device specific adaptation code to generate it,so you should not rely on receiving it. However, if it is sent, youshould see KLinkLayerOpen again once data transfer is possibleagain.INFORMATION GATHERING AND CONNECTION MANAGEMENT195• KConnectionFailure – the connection attempt has failed.• KConnectionStartingClose – a disconnection has been initiated.• KLinkLayerClosed – the connection has been terminated.Applications subscribe for progress notifications like this:TNifProgressBuf iProgBuf; // member of class...iConn.ProgressNotification(iProgBuf, iStatus);This will complete when a progress change has occurred, and theTNifProgress will contain the latest progress value.
TNifProgressBuF contains two parameters:• iStage – the stage of the connection. One of the values definedabove, or a bearer specific stage. Applications should be preparedto process, or at least ignore, unknown stages because they may notalways be aware of which bearer is being used.• iError – the error code at this stage. If the connection stage issuccessful, this will be KErrNone, otherwise it will be set to thereason why the stage has failed. An error is always followed by areturn to the uninitialized state, possibly passing through a series ofother stages on the way.If your application is only interested in one particular status, such asan indication that the connection has been successfully activated, therequired status can be included as an additional parameter. This willcomplete once the requested stage has been reached.iConn.ProgressNotification(iProgBuf, iStatus, KLinkLayerOpen);Because these are asynchronous notifications, and stage changes canoccur rapidly during connection establishment and termination, applications should not assume that all stage changes will be retrieved by theapplication.
Stages may be missed if the application has not re-issued anew notification before the stage change occurs and this means that theerror notifications may also be missed. If an error occurs, the stage willeventually return to the uninitialized stage but the error is stored so that theapplication can always retrieve the reason for the failure/disconnectionusing LastProgressError().Because stages can be missed, if the application really wants to knowthe current stage, it should use the synchronous Progress() method to196IP AND RELATED TECHNOLOGIESretrieve the current progress information.
A typical RunL() for detectingthe error that has caused a connection to be terminated could looklike this:void CProgressTracker::RunL(){if(iStatus.Int()==KErrNone){// Repost the notification immediately to minimise chance// of missing new notificationsiConn.ProgressNotification(iProgBuf, iStatus);if(iProgBuf().iStage==KConnectionUninitialised){iConn.LastProgressError(iProgBuf());err = iProfBuf().iError;// now do something with err!}SetActive();}else{// some problem getting progress notifications}}6.5.2 Active Connection InformationRConnection provides the ability for applications to retrieve differenttypes of information about an active connection.Configuration informationApplications are able to read configuration information for the connectionthey are currently using.
This saves the application from needing touse the CommsDat interface described in section 6.3.2 to retrieve theinformation, as this can all be done using RConnection. The settings areread in the form ‘‘<table name>\<field name>’’ (and there are constantsdefined for each of the tables and fields defined in cdbcols.h).
Forexample, the IAP settings are stored in the IAP table, so to get the IAP ID(an integer), use ‘‘IAP\ID’’._LIT(KIapTableIdField, "IAP\Id");TInt iapId = 0;err = iConn.GetIntSetting(KIapTableIdField, iapId);Or to read the IAP name:_LIT(KIapTableNameField, "IAP\Name");TBuf<KCommsDbSvrRealMaxFieldLength> iapName;iConn.GetDesSetting(KIapTableNameField, iapName);QUALITY OF SERVICE1976.6 Quality of ServiceSome applications may have specific requirements for data they send andreceive in terms of latency or bandwidth.
Applications can specify theserequirements by setting QoS parameters to ensure the correct behaviorfor the application.Different network technologies implement QoS in different ways – atthis time, only 3G packet data networks have a QoS implementationin Symbian OS. Therefore this section is only currently applicable toapplications using 3G packet data connections.6.6.1 3G QoS3G QoS is defined in 3GPP 23.107 (R99). As is usual for QoS, it allowsdifferent services on a device to request different behaviors of the network,and the network operators can allocate different resources (bandwidthetc.) depending on the requirements of the active services.
Examplesof this are where an IP telephony application requires low latency (ifthe packets arrive too late to be played they will be thrown away andsound quality will decrease, or suffer from dropouts), whereas an musicor video download requires high bandwidth. On 3G data networks, thisis negotiated with the network via a secondary PDP context. As discussedat the start of this chapter, a secondary PDP context is a PDP contextcarrying some subset of the IP traffic for this connection, which has aspecific QoS profile. Secondary PDP contexts do not have their own IPaddress, the IP address of the network connection is shared between theprimary and secondary contexts (so the same IAP will be used for theprimary and secondary context, and obviously they will connect to thesame network).The main concept of 3G QoS is the traffic class – there are four trafficclasses, as shown in Figure 6.9.There are four main characteristics to consider when thinking aboutQoS:ConversationalStreamingInteractiveBackgroundFigure 6.9GuaranteedLow delayReal timeGuaranteed delay(but not necessarily low delay)Low delay(but not guaranteed error free)No guarantee on errorfree delay3G traffic classes198IP AND RELATED TECHNOLOGIES• Bandwidth – this is the rate at which the connection can transferdata.
Obviously some services want as much bandwidth as possible, for example, downloading, whereas others have fairly minimalrequirements, for example, VoIP.• Latency – this is the delay through the network between two endpoints. For ‘real-time’ services where some form of conversation isinvolved it is important that this be kept low enough that it doesn’thamper communications – for voice networks a delay of less that150 ms is often unnoticeable.• Jitter – this is the variation in delay through the network, and isnormally smoothed out at the receiver with the use of a jitter buffer.However, use of a jitter buffer increases the latency, so for someapplications (voice again being a prime example) it is desirable tokeep the size of the jitter buffer small.• Packet loss – this is obviously the number or percentage of packetsthat are dropped during transfer from one endpoint to another.6.6.2 Introducing RSubConnectionA subconnection in Symbian OS represents a channel as part of a networkconnection that has specific parameters associated with it.
In the caseof the 3G packet data network, it represents a secondary PDP contextvia the RSubConnection API shown in Figure 6.10. These behave ina similar way to RConnection but with the ability to also request QoSparameters for the connection. Each RConnection object has an implicitsubconnection associated with it, which is automatically assignedthe default QoS parameters (as configured by the network operator orphone manufacturer). This is likely to be best-effort bandwidth, with noother guarantees.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
