The Symbian OS (779886), страница 53
Текст из файла (страница 53)
At the top of the stack, the wireless session protocol (WSP)behaves like a binary-encoded HTTP. Unlike HTTP, WAP enables bothpull and push models. In the pull model, clients make requests to a WAPgateway that responds by sending data. In the push model, the gatewaypushes data to the client, without a client request.While the full WAP stack consists of multiple protocols, WAP DatagramProtocol (WDP) is the critical underlying mechanism, defining a binaryencoding for datagrams over a bearer network, which can be any of GSM,CDMA, SMS, GPRS or 3G network protocols.Symbian supplied a full WAP-stack implementation in Symbian OSv7.
However, where licensees supplied a WAP browser it was generallytightly coupled to a particular WAP-stack implementation and wherethey didn’t the Symbian stack was redundant in any case. Therefore fromSymbian OS v8, Symbian OS implements a ‘short’ stack that only supportsWAP messaging features (which, for example, are used by the MultimediaMessaging Service), providing connectionless WAP Push, connectionlessWSP, and WDP.The implementation consists of the Messaging API and the WAP ShortStack, which is supplied as a reference implementation only. Theseprovide the client APIs and implementation for WAP messaging overGSM SMS bearers. (Note that the mapping of WDP to CDMA SMS notimplemented.)An important use case for WAP is as the carrier for MMS delivery.Unlike SMS, which is transmitted over network-signaling channels, MMSuses data-traffic channels and, hence, requires a transport technology(SMS relies on network-specific signaling mechanisms as its bearer).An advantage of WAP is that it provides a uniform transport protocolregardless of the underlying network type (GSM, GPRS, CDMA or 3G).WAP push is based on notification sent to the terminal over SMS,followed by a WSP ‘get’ call to fetch the message.
MMS is thereforeindependent of the network type (because WAP implementations runon all network types) and interoperable (because TCP/IP is used on thenetwork side to link WAP gateways and can link gateways on differentnetworks, for example, GSM and CDMA or UMTS).ArchitectureThe general structure of Networking Services in Symbian OS will berecognizable to those familiar with the standard OSI 7 layer networkingmodel and corresponds roughly to a utility layer plus the lower fourlayers.
See Figure 9.23.236THE COMMS SERVICES BLOCKSocket mechanismApplicationsTCP/IPv4/v6Other transport-levelextensionsTransport (4)Network (3)Network interface selectionDatalink (2)Network interface implementation(link layer)Physical (1)Device drivers/Hardware interfaceFigure 9.23 Networking Services mapped against the OSI modelThe higher layers of the OSI model are mapped by components inthe higher layers of Symbian OS, particularly in the Application Serviceslayer.The OSI model is a generic abstraction and not a rigid specification butunderstanding the mapping helps to understand the Symbian networkingimplementation.
Roughly, the Symbian OS layers are as follows, workingtop down:• networking services and utilities including network security, networkdaemons, plus the WAP stack implementation• network-specific extensions to the Socket Server and Network Connection Manager• core network protocols, the TCP/IP stack and its extensions• network interface management agents• network interface implementations.The higher-level components provide application-level interfaces, themiddle-layer protocol implementations are tightly bound to the socketsabstraction, through which all networking services are accessed, andthe lower levels provide the interfaces to the available communicationsbearer technologies.NETWORKING SERVICES237From a client perspective, the complex interactions between the networking components, the communications framework and the short-linkand telephony bearer services are hidden behind the Socket Server.However, it is useful to have at least a general picture of the pattern ofinteraction.When a Socket Server sub-session is opened by a client requesting aTCP/IP protocol socket, the request is passed to the TCP/IP stack, whichtries to start an outgoing connection.
If the stack fails to find an interfacethat will allow it to reach the selected destination, it reports its failure backto the Socket Server, which then requests the Network Interface Managerto load and start a connection agent of suitable type. Depending on itstype, the agent requests a connection from either the Telephony Server orthe C32 Serial Server. When the connection is established, the NetworkInterface Manager loads and starts a NIF module, which implements therequired Network Interface and negotiates authentication and other linkcharacteristics (for example, encapsulation and compression) and finallyacquires an IP address. The Network Interface manager then binds theNIF to the TCP/IP stack.Design GoalsThe original design goals of Symbian OS Networking Services werebased on dial-up access to a network via either a fixed-line modem ora mobile phone.
The expected networking applications were standardInternet and web applications, for example email and browsing. Adequatedata throughput and the ability to virtualize networking services over anavailable serial bearer were the key considerations.Network protocols were also considered important as a way of standardizing support for connectivity with desktop computers for datasynchronization and backup.The increasing specialization of Symbian OS for mobile phones, andthe evolution of mobile phones into true network devices as packet services have begun to dominate, has required almost continuous evolutionin the architecture and implementation of Networking Services, to keepin step with rapid technological advance, rapid adoption of advancedtechnologies into mobile phones and the push to provide infrastructurefor new services and applications.Networking has become mainstream for telephony as the basis forhigh data throughput services such as two-way video conferencing andaudio and video streaming.
Direct network connection over Wi-Fi is alsorapidly becoming a support requirement for mobile phones.VoIP pushes these trends to their logical step, in effect subsumingtelephony into networking.238THE COMMS SERVICES BLOCKComponent CollectionsTCP/IP Security CollectionThese components implement secure networking, supporting transportlevel security (security at the level of individual IP packets) andconnection-oriented security (which is used, for example, to provideVPN support services to application clients running on Symbian phones).See Figure 9.24.TCP/IP SecurityTLSIPSecVPNFigure 9.24 TCP/IP Security componentsTable 9.12 TCP/IP Security ComponentsComponent NameDevelopment NameTLSTLS, TLSPROVIDERIPSecIPSECVPNVPNAPI, VPNCONNAGT,VPNMANAGER• The TLS component is an implementation of Transport Level Security(TLS) including SSL Secure Sockets, which provide encryption perpacket, supporting application-level encryption and authenticationbased security, for example for secure web services.
Client authentication is based on key management and certificate handling, includingsupport for external cryptography modules (‘secure tokens’), forexample based on a phone smart card.• The IPSec component operates at a lower level (i.e. network level)and is principally designed to enable secure networks, for exampleVPN, based on policy.• The VPN component provides policy-based connection managementand gateway interoperability for VPN connections, i.e.
it enables usersto connect to VPNs.TCP/IP Utilities CollectionThis collection contains implementations of standard networking ‘daemon’ server utilities. See Figure 9.25.NETWORKING SERVICES239TCP/IPUtilitiesDNDDHCPFigure 9.25 TCP/IP UtilitiesTable 9.13 TCP/IP UtilitiesComponent NameDevelopment NameDNDDNDDHCPDHCP• DND is a DNS implementation that makes DNS queries to the networkand listens for and responds to local queries.• The DHCP component is a Dynamic Host Configuration Protocol(DHCP) implementation used by the PAN Profile and other networkingcomponents.WAP Stack CollectionSymbian provided a full WAP stack implementation in Symbian OSv7. Versions later than Symbian OS v8 implement only a ‘short’ stack,providing client APIs for connectionless WSP, connectionless Push andWDP.
See Figure 9.26.Table 9.14 WAP Stack ComponentsComponent NameDevelopment NameWAP Message APIWAPMESSAGEWAP Short StackWAPSTACK• The WAP Short Stack component is a cut-down WAP stack supportingWAP messaging, that is, WAP datagrams, WAP Push messaging andWAP StackWAPMessageAPIFigure 9.26WAPShortStackWAP Stack components240THE COMMS SERVICES BLOCKWSP but not full WAP browsing.
It is supplied only as a referenceimplementation. Vendors replace it with their own short or full WAPstack implementations.• The WAP Message API implementation provides APIs for WAP Push,connectionless WSP and WDP datagrams.Sockets API Extensions CollectionThe Internet Sockets component is a DLL that provides a library of utilityclasses and generally useful constants, which specifically support usingInternet sockets, to store and manipulate IP addresses, routes, and so on.ESock APIExtensionsInternetSocketsFigure 9.27Sockets API ExtensionsTable 9.15 Sockets API Extensions ComponentsComponent NameDevelopment NameInternet SocketsINSOCKClients access the Internet Sockets through the generic sockets clientAPI and use the TCP/IP-specific utility classes to perform the IP-specificmanipulations.
Clients link against the Internet Sockets library. SeeFigure 9.27.Subconnection Interface CollectionThis is a utility component used by QoS clients to create and packagethe QoS parameter list. Parameters are set using the RQoSChannel class.See Figure 9.28.SubconnectionInterfaceSubconn.Params.Figure 9.28 Subconnection InterfaceNETWORKING SERVICES241Table 9.16 Subconnection Interface ComponentsComponent NameDevelopment NameSubconnection ParametersNetwork Protocol Plug-ins CollectionThis collection contains the core TCP/IP functionality including the TCP/IPstack, which supports both v4 and v6 standards, the hook mechanismthat allows access to packets for inline processing (for example allowingpackets to be encrypted ‘in place’ as they flow through the stack), andIPSec and QoS implementations. See Figure 9.29.Table 9.17 Network Protocol Plug-insComponent NameDevelopment NameIP Event NotifierIPEVENTNOTIFIERTCP/IPv4/v6 PRTTCPIP6IP HookINHOOK6QoS Framework PRTQOS, QOSLIB, PFQOSLIB,SBLPAPICore IPSec PRTNo unit• The IP Event Notifier PRT is implemented as an IP Hook and raisesevents to clients based on state changes in the TCP/IP stack.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
