Symbian OS Communications (779884), страница 56
Текст из файла (страница 56)
The OBEXspecification is available (for a fee) from www.irda.org.10.1.1 OBEX FundamentalsThe OBEX protocol is asymmetric, meaning that the two entities involvedin an OBEX transfer play different roles – OBEX client and OBEX server.Whilst connected by a session, an OBEX client and server are termed asOBEX peers. The terms client and server are used here in the traditionalsense that the client makes requests of the server, and the server providesa response to these requests.In OSI model terms, OBEX belongs in the session layer. It defines astructured dialog where a client sends request packets to a server, afterwhich the server sends response packets to the client.
This request–response exchange happens in strict rotation; the server may never senda response packet without having first received a request packet, and aclient may never send a second request packet without having receiveda response to its first request.The formation and sending of request packets begins when theapplication acting as the OBEX client (known forthwith as the OBEXclient application) issues an OBEX command. There are surprisingly fewstandard OBEX commands in version 1.2 of the OBEX specification (theversion supported by Symbian OS):• Connect – establish an OBEX session• Disconnect – close the OBEX session• Put – transfer an object from the OBEX client to the OBEX server• Get – transfer an object from the OBEX server to the OBEX client• SetPath – alter the path on the OBEX server• Abort – abandon the current OBEX commandOBEX OVERVIEW275A Connect, Put or Get command may result in multiple request–response exchanges between the OBEX client and server before thecommand can be said to be complete.
Mechanisms are provided withinthe protocol to allow the client and server to determine when a particularcommand is completed. The Disconnect, SetPath and Abort commandsare always dealt with in a single request–response exchange.Figure 10.1 shows an example of how an individual OBEX command(in this case a Put) translates into multiple request–response exchanges.Please note that the application/OBEX implementation split is SymbianOS-based, although the traffic ‘on the air’ would follow a similar patternregardless of the OS in use.With such a compact command set, it may be appreciated that theflexibility of OBEX is mainly a result of the rich model provided fordescribing the transferred objects themselves.
The OBEX object modeluses headers to describe these objects.10.1.2 OBEX HeadersIn the OBEX protocol, most information is conveyed as headers. Thereare a large number of different possible header types, but all of theseheader types can be split broadly into two groups: headers used torepresent objects to be transferred (these belong to the ‘object model’)and headers used by the OBEX protocol itself for its own purposes, suchas authentication and the selection of directed services.When present in an OBEX packet, each header consists of one byte ofheader information (HI) which identifies the header type and encoding,followed by multiple bytes of header value (HV) which encodes theactual value of the header.
There are four different encoding types thatSymbian device with OBEX ClientOBEX Client applicationTraffic "on the air"Symbian device with OBEX ServerOBEX ServerOBEX ClientOBEX Server applicationPut command()Put request packet()Put command notification()Object in which data is to be stored()Put response packet()Put request packet()Put response packet()Put request packet (final)()Put response packet (final)()Put command completion()Put complete notification()Figure 10.1 Simplified view of OBEX Put command processing in Symbian OS, showingmultiple packet exchanges for a single command276OBEXcan be used for a header: a length-prefixed null terminated Unicodestring; a length-prefixed byte sequence; a one-byte quantity; and a fourbyte quantity.
The encoding type for a header is held in the upper twobits of the HI, with the lower six bits of the HI identifying the header type.Some examples are show in Table 10.1.Headers used in the object modelThe object model describes how OBEX represents objects. An objectis represented as a collection of associated headers. During an objecttransfer, the main payload or ‘body’ of an object is represented by oneor more body headers. There may be any amount of metadata associatedwith an object – for such metadata, there are specialized headers typessuch as Name, Type and Date.The headers included in a particular transfer, and the way in which theheaders are interpreted, will depend largely on the nature of the servicebeing used by the OBEX client and provided by the OBEX server. Forinstance, if a file is being transferred to another device for storage, theName header will be of primary importance to convey the file name.
Ifthe file is being transferred purely to be played (e.g., a JPEG file beingsent to a media player for display), the Type header might be of greaterimportance.A few important object model header types are listed below. Moredetails on these and other headers can be found in the OBEX specification.Body and end-of-body headers The main payload of an object canrepresent almost anything: the contents of a file, a contact, a piece ofXML, the result of a database query, etc. When transferred using OBEX,the payload usually (unless it is very small) has to be fragmented toallow it be encoded into OBEX packets, which have a finite capacity.The payload is fragmented into zero or more Body headers and/or anEnd-of-Body header, and sent in ordered sequence.
These headers arereassembled in the same sequence by the receiving OBEX client or server.The Body header and End-of-Body header perform almost identicaltasks, and both header types can carry payload data. The End-of-BodyTable 10.1 Some common header types and their HI valuesHI valueHeader typeEncodingUsage0x01NameNull terminated UnicodeName of the object0x42TypeByte sequenceDescribes media type ofobject0xC3LengthFour-byte quantityDescribes number ofbytes in object payloadOBEX OVERVIEW277header differs from the Body header only because it has a different HIvalue, which indicates that it contains the final piece of the object’spayload. As a result, while the payload may be split into a number ofBody headers, only a single End-of-Body header is allowed.For objects with no payload, the End-of-Body header may be includedor omitted from a transfer.
For some services such as file transfer, however,the presence of an empty End-of-Body header has a distinct meaning fromthe absence of any End-of-Body header at all (e.g., the difference betweenan empty file and no file at all).Name The Name header represents the name of the object beingtransferred. As always, the interpretation of the name will depend onthe OBEX service being used; for an OBEX file transfer for example, theName header will be used to represent the file name.Type The Type header represents the object type being transferred.Usually, the Type header contains an IANA registered media type (e.g.,‘text/html’) and is used by the receiving OBEX client or server to determinethe action to be taken to deal with the received object.
Depending onthe OBEX service being used, the Type header may be unnecessary oroptional – the service may well determine what the object type is byother means.Length If the number of bytes in an object is known before a transferbegins, the Length header may optionally be used to represent thatnumber. The header is transferred early in the object exchange as itprovides useful data for the receiver – it can be compared with availablestorage space to determine whether the transfer should be allowedto continue, and it can be used during a transfer to determine whatpercentage of an object has been transferred so far.
It should also benoted that the Length header is not guaranteed to be an absolutelyaccurate size of the object; it is intended for use in situations such asdisplaying a progress bar where exact numbers are not necessary.HTTP To allow reuse of some HTTP-based features, the OBEX specification allows HTTP headers to be represented and transferred as part ofan object.Headers used by the OBEX protocolAs well as those headers used in the object model, there are additionalheaders used internally by OBEX to control various aspects of the protocol.Authentication challenge and authentication response headers Theauthentication challenge and authentication response headers provide theOBEX protocol with the ability to perform password-based authenticationduring an exchange.
This authentication is quite flexible:278OBEX• the OBEX client can authenticate the OBEX server• the OBEX server can authenticate the OBEX client• both the OBEX client and the OBEX server can authenticate eachother.Or, of course, authentication can be missed entirely, for instance wherethe underlying transport provides inbuilt security (e.g., Bluetooth pairingor IrDA’s requirement for line of sight).Although the OBEX specification allows authentication to be performedfor any command, in practice it is most commonly performed during theConnect command used to establish an OBEX session.Target, Who and Connection ID headers The OBEX specificationdefines the concept of a directed connection.
This is a means by which anOBEX client can be routed and connected to an OBEX server providingthe particular service the client wants. This is an optional feature, mostuseful when many OBEX services have been multiplexed over a singleunderlying transport connection. The Target, Who and Connection IDheaders all play a role in the creation of directed connections.• The Target header is sent by the OBEX client during a directedconnection attempt to identify the service it wishes to connect to.• The Who header is sent by the OBEX server during a directedconnection attempt to identify the service it is offering.• The OBEX server provides the OBEX client with a Connection IDheader value when it accepts the OBEX client’s connection to forma session.• The same Connection ID header is used by the connected OBEXclient to identify its session to the OBEX server during subsequentcommands.Figure 10.2 illustrates this sequence.Please note: using directed connections is often unnecessary since thetransports underlying OBEX offer their own means of differentiating andselecting services (Bluetooth has SDP, IrDA has IAS) and their own multiplexing and routing capabilities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
