Symbian OS Communications (779884), страница 59
Текст из файла (страница 59)
The fundamental requirementof an OBEX transport is that it should be reliable – that is to say, transmission errors will be detected and handled in the transport layer. TheOBEX protocol does not have any inbuilt mechanism to recover frommalformed, missing or out of order packets. The transport responsible forsending the OBEX packets must ensure that they are delivered correctlyand in the order of sending, or where an unrecoverable situation arises,notify OBEX that the transport link is no longer usable.Bringing up an OBEX transport linkBringing up an OBEX transport link is usually the responsibility of theOBEX client. In order to do this, the client will need some way to discoverand address the OBEX server that it wishes to connect to. The process bywhich the client and server arrange for this to happen is called servicediscovery.Service discoveryAn OBEX server will generally use transport-specific mechanisms toadvertise itself in order that OBEX clients are able to find it, work outwhat services it offers and how it can be addressed.
Once it has createdthis advertisement, the OBEX server waits passively to be connected to.Correspondingly, the OBEX client will use transport-specific mechanisms to discover the OBEX server (and the device on which it isrunning), and how to address the OBEX server. This information can thenbe used to establish the OBEX transport link so that packet exchange canbegin.Let’s have a look at the transport-specific mechanisms.Bluetooth service discovery OBEX servers running over Bluetooth useSDP to advertise services. Each Bluetooth service, OBEX or otherwise, hasa corresponding SDP record which identifies the service being offered,288OBEXand the means to address that service in a Bluetooth-specific way. Theaddress of an OBEX service running over Bluetooth is a combination ofthe RFCOMM server channel number and the Bluetooth device address.There may be additional requirements on an OBEX service to ensure thatOBEX clients can connect to it over Bluetooth, such as ensuring that thedevice is connectable and, if dealing with an unpaired Bluetooth device,discoverable.
The Bluetooth class of device (CoD), specifically the majorservice class, may also require modification.OBEX clients running over Bluetooth can use the device discoveryprocedures identified in the GAP profile to identify devices offeringobject transfer services (based on the major service class bit field in theCoD) and their device addresses. Once the device has been found, theOBEX client can perform a more detailed query, using SDP, to gatherdetails on the remote device’s OBEX services, if any. The SDP queryshould indicate the type of OBEX services on offer, and provide the finalnecessary piece of addressing information, the RFCOMM server channelnumber.The subject of SDP, along with discovering, connecting to and queryingservices (including getting and setting CoD information) on Bluetoothdevices is covered in greater detail in Chapter 4.IrDA service discovery OBEX servers running over IrDA use IAS toadvertise services.
The OBEX specification defines a well-known service,the ‘Default OBEX server’, identified by the IAS class name ‘OBEX’. OtherOBEX services must define their own specific class name with whichthe associated OBEX server will be registered and OBEX clients seekingthat service can use to query IAS. An attribute ‘IrDA:TinyTP:LsapSel’must be present for each registered OBEX class advertised using IAS,whose attribute value identifies the TinyTP LSAP to which the service isbound.When a device offers an OBEX service over IrDA, the device must alsoset the OBEX hint bit in the IrLMP hint bitfield.
This bitfield fulfils a similarpurpose to the major service class bitfield in the CoD in Bluetooth.More details on connecting to and querying services on IrDA devicescan be found in Chapter 5.Bringing down an OBEX transport linkAn OBEX transport link can come down at any time, and any robustOBEX application must be prepared to deal with this. The transport linkmay come down because one of the OBEX peers decided that they wouldnot or could not continue with the OBEX session, or because of linkfailure – Bluetooth devices can move out of range, IrDA beams can beblocked, etc.OBEX IN SYMBIAN OS28910.2 OBEX in Symbian OS10.2.1 Origins and DevelopmentOBEX first appeared in EPOC Release 5 (ER5), the precursor to SymbianOS that was developed for the Psion Series 5mx.
In that release, OBEX ranover the IrDA transport only and was intended for simple point-to-pointbeaming of items such as vCards, replacing an earlier Psion proprietaryscheme.The OBEX implementation in Symbian OS v9.1 is the result of incremental development of that first OBEX implementation, and the APIs arestill to a large extent source compatible with that original version. Therequirement to maintain source compatibility has resulted in some newerfeatures being added in perhaps unexpected ways, as we will see later on.10.2.2 Feature SetThe Symbian OS v9.1 OBEX implementation supports the followingfeatures:• OBEX client and server (OBEX version 1.2)• IrDA, Bluetooth and USB transports4• OBEX authentication on connection• All standard OBEX version 1.2 commands (Connect, Disconnect, Put,Get, SetPath, Abort)• All standard OBEX headers and user-defined headers• Transfer of OBEX objects to and from RAM or file• Single or double buffering of received file data with user definablebuffer sizes• User-defined OBEX packet sizes• Target/Who/Connection ID header support.There are also some notable omissions from the Symbian OS OBEXimplementation that an application developer should be aware of:• Capability object (although this may be provided by higher levelsoftware)• OBEX level routing/multiplexing.4USB resources, including the OBEX USB transport, are generally reserved for use bySymbian’s licensees, so are not covered in this chapter.290OBEXSymbian OS v9.2 sees the continued development of the OBEX implementation, including:• Improved OBEX server API to enable asynchronous processing ofrequests• Ability to set timeouts for OBEX client commandsIt is anticipated that future versions will also see the introduction ofAPIs for data streaming over OBEX, so that transfers are not limited byavailable RAM.10.2.3 API Structure, Executable Structure and Header FilesThe Symbian OS OBEX API splits into three parts: an API used to createobjects for sending or receiving into; the OBEX client API; and the OBEXserver API.
In a typical application, the object API is used in conjunctionwith one of the other two APIs.Applications can access these APIs by linking to irobex.dll. Inthis DLL, OBEX support is implemented as a group of interrelatedclasses whose code runs in the same thread as the application usingOBEX. It is important to note that these classes include CActivederived active objects that need their host thread to have an installedactive scheduler to operate. This use of active objects within theOBEX implementation also has implications particularly for OBEX clientapplication writers, who should avoid blocking the thread waiting forasynchronous OBEX commands to complete – in particular any use ofUser::WaitForRequest() or WaitForAnyRequest() will causeproblems.The headers that an application needs to include depend on the natureof the application, but in general following headers are used:obexobjects.hobexheaders.hobexclient.hIncluded by OBEX applications which need touse the classes representing the OBEX objecttypes (CObexBaseObject, CObexBufObject,CObexFileObject etc.).
Effectively, thismeans all (useful!) OBEX applicationsIncluded by OBEX applications which need touse classes representing OBEX headers andheader sets – this means all OBEX applicationsusing the recommended means to manipulateheaders associated with OBEX object typesIncluded by OBEX client applicationsOBEX IN SYMBIAN OS291obexserver.hIncluded by OBEX server applicationsobexconstants.h Included for access to classes defining (amongstother things) transport settings for OBEX clientsand serversEach of these API areas will now be covered in depth.10.2.4 OBEX Object APIsThe OBEX object API provides a group of classes to represent OBEXobjects (see Figure 10.4).
The same classes can be used for both sendingand receiving objects.Each OBEX object consists of a group of (non-body) headers, and somerepresentation of the body data. How the body data is represented variesdepending on the class used. One of the two main OBEX object classes(CObexFileObject) allows body data to be sent from, and received to, afile; the other class (CObexBufObject) allows body data to be sent from,and received to, a RAM-based buffer. In fact, CObexBufObject alsooffers the ability to read from and write to files, as will be explored later.CObexBaseObjectThe representation of headers (other than the body headers) remains thesame for all classes, and so this functionality is located in a base class,CObexBaseObject.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
