Symbian OS Communications (779884), страница 29
Текст из файла (страница 29)
and Vlissides, J. (1995) Design Patterns: Elements of reusable object-oriented software, Addison-WesleyProfessional.5Infrared5.1 IntroductionWireless communication started on Symbian OS with the support forthe infra-red protocol stack standardized by Infrared Data Association(IrDA). IrDA provides a networking stack optimized for ad-hoc information exchange, and can be used for many purposes. With the introductionof alternative technologies, however, its major current use case is exploiting the large installed base of IrDA transceivers on laptops and othercomputers, and for one-off exchanges of small amounts of data.
Itsprimary advantages are speed and simplicity of connection establishment, together with the perception of enhanced security because of theline-of-sight requirement.In this chapter we examine the IrDA technology and show how theconcepts translate to the Symbian OS implementation. We cover deviceand service discovery, listening and connecting sockets at different levelsin the protocol stack, and provide an overview of the socket options andioctls provided for advanced purposes.5.2 Infrared OverviewThe IrDA standards cover data communication over infrared light at alllevels – from hardware to application.
This includes details such as rangeand light cone angle at the hardware level, working up to device discoveryand addressing, service discovery, and creating a reliable, multiplexeddata link.Key benefits of the IrDA protocols and associated hardware includevery low cost and high levels of maturity, which together have greatlyincreased market penetration. Until very recently, IrDA was the mostpopular short-range wireless link on a variety of devices, including126INFRAREDmobile phones, PDAs and laptop computers. Bluetooth was createdmore recently to fulfil a similar role to IrDA, but infrared still maintains a significant presence in mobile devices – particularly in the Asianmarket.
Key differences between IrDA and Bluetooth include range,line of sight and device discovery and connection setup times (seeTable 5.1).Due to these differences, IrDA protocols still have a useful role toplay, particularly when small objects need to be transferred betweentwo devices that will not be frequently connected. However, the mostimportant factor in deciding whether to use infrared is the availability ofhardware in products. Whilst many phones in the market have Bluetoothfunctionality built in, some phones are now omitting the infrared port,especially in European markets.It is also worth noting that the Bluetooth standards body are consideringmethods to address the differences in device discovery and connectionsetup times in relation to IrDA, so devices supporting future versions ofthe Bluetooth specification are likely to approach the same performanceas IrDA.Table 5.1 Key differences between IrDA and BluetoothIrDABluetoothRange1m10 cm, 10 m or 100 m(10 m most common)Line of sightRequiredNot required, althoughobstacles may reduce rangeDevice discovery time<0.5 s10s of seconds, dependingon number of devicesfound.
Pairing removes thisdelay when repeatedconnections to the samedevice are likelyConnection setup time<0.5 s<10 sSpeedSerial Infrared (SIR):up to 115 kbit/s768 kbit/sFaster IrDA physicallayers are specifiedbut are not supportedby Symbian OSEnhanced Data Rate (EDR):1.4 or 2.1 Mbit/sINFRARED OVERVIEW1275.2.1 The IrDA StackFigure 5.1 shows a block diagram for an IrDA stack. At the bottom ofthe IrDA stack is IrPHY – the physical layer. This layer is too low tobe of much interest when developing applications using IrDA, but isresponsible for defining the angle of the light cone, the range of the beamand the raw link speed.Moving up a layer is IrLAP – the Link Access Protocol. This layer provides for establishing reliable connections, so includes device discoveryand addressing, connection establishment and teardown, reliable dataexchange and link level flow control.
It is worth emphasizing that thislevel in the IrDA stack provides the reliability, so all higher layers areautomatically reliable.Next comes IrLMP – the Link Management Protocol. This is dividedinto two sections: LM-MUX (often referred to as IrMUX on SymbianOS) and LM-IAS. IrMUX provides multiplexing, allowing a number ofapplications to share the connection. It provides 127 stream endpoints(LSAP SELs – Logical Stream Access Point Selector, often referred to asports) per device, although 16 of these are multicast, and LSAP SEL zero isreserved for IAS (Information Access Service). Some IrDA implementationsmay allow the source and remote LSAP SEL together to define a channel,IrCOMMLM-IASTinyTPLM-MUX (IrMUX on Symbian OS)IrLMPIrLAPIrPHYKEYApplication-level access pointsFigure 5.1 IrDA stack128INFRAREDso increasing the number of channels available. IrMUX is the lowestprotocol layer exposed on Symbian OS, and is available as a sequenceddatagram socket.
It is worth noting that, particularly with the flow anderror control in IrLAP, it is possible to deadlock an IrDA link if two IrMUXconnections are active. It is possible to mark a connection as exclusive toprevent this problem – all other links are flow-controlled off. In platformsecurity enabled versions of Symbian OS, i.e. v9.1 onwards, the abilityto perform this operation is protected more strongly than standard datatransfer.As availability of IrMUX LSAP SELs is limited, IrDA profiles tend to usedynamic selection of these identifiers. Unlike HTTP/TCP, which alwayslistens on port 80, OBEX (the IrDA equivalent of HTTP) may listen on anyLSAP SEL, possibly changing each time a device is discovered.1 To allowconnection to these dynamic ports, a device can connect to the singlewell-known LSAP SEL zero, and query the IAS database.IAS queries generally consist of a class name and the attribute inwhich we are interested for that class.
Class names are a simple textstring – certain services use certain well-known strings, and other servicescan choose their own strings. When choosing your own string it issensible to prefix it with a unique value – your company name, forexample – to reduce the chance of clashes. The server then respondswith the corresponding value for that attribute. This is easier to see usingan example.QueryClass nameAttributeOBEXIrDA:TinyTP:LsapSelFigure 5.2 A typical IAS query for the default OBEX serviceFigure 5.2 shows a query for information about the default OBEXservice, specifically the LSAP SEL on which it is listening.Figure 5.3 shows the result, telling us that the service is running onLSAP SEL 2.To address the potential deadlocks of IrMUX, Tiny Transport Protocol(TinyTP) is the next layer.
TinyTP provides credit-based flow control on aper-channel basis rather than globally across the entire link. It is otherwiseidentical to IrMUX, other than (in the IrDA specification) allowing foreither a stream interface or a sequenced datagram interface. Most IrDAapplications should use this layer unless they have a good reason not to.ResponseFigure 5.3TypeValueInteger2A typical IAS response for the default OBEX service1Here we refer to the general OBEX service. OBEX services offered by specific applications may also exhibit this behaviour, as they should not be hard-coding a ‘standard’LSAP SEL either, for the reasons described in this section.IRDA IN SYMBIAN OS129The final protocol is IrCOMM – serial port emulation.
To describeIrCOMM purely as a serial port emulation is oversimplistic, although it isusually exposed to applications through a serial port-like interface. Thereare multiple ‘levels’ of IrCOMM – IrLPT; 3-wire raw; 3-wire cooked;9-wire; and Centronics. The names change as functionality increases.IrLPT and 3-wire raw are essentially the same, although they use IASslightly differently. The biggest drawback is that they run directly overIrMUX, creating the possibility for deadlocks. Neither variant providesemulated control lines, so the RS-232 hardware flow control signals areunavailable. 3-wire raw runs over TinyTP and provides a control channel.Being a three-wire serial port, this control channel still does not carryflow control lines, but it can be used to signal a baud rate (although thisis purely advisory – the emulated link will actually run at the physicallink speed), communications errors, XON/XOFF characters and the breaksignal, among other things.