Symbian OS Communications (779884), страница 58
Текст из файла (страница 58)
The OBEX server receives the Connect request packet, and extractsthe authenticate response header and verifies the authenticity of theOBEX client. If the authentication is successful, the OBEX serverresponds to the OBEX client with a Connect response packet with aresponse code value ‘Success’. If the authentication is unsuccessful,the OBEX server may respond with a Connect response packetcontaining a response code indicating the failure of the connection.5. (Assuming successful authentication) the OBEX client receives theConnect response packet, and the OBEX session has been connected.Connect (both client and server authenticate each other)1. The OBEX client sends a Connect request packet to the OBEX servercontaining an authenticate challenge header.2. The OBEX server receives the Connect request packet.
It then preparesand sends a Connect response packet to the OBEX client withthe response code value ‘Unauthorized’ and another authenticatechallenge header, this one originating from the OBEX server.3. The OBEX client receives the Connect response packet, and extractsthe authenticate challenge header. It then prepares and sends a second Connect request packet similar to the first (including a copy ofthe original authentication challenge header), but this time includesan authenticate response header to satisfy the OBEX server’s requirements.4.
The OBEX server receives the Connect request packet, and extractsthe authenticate response header and verifies the authenticity of theOBEX client. If the authentication is successful, the OBEX serverresponds to the OBEX client with a Connect response packet with aresponse code value ‘Success’, and an authenticate response headerof its own to satisfy the OBEX client’s requirements.
If the authentication is unsuccessful, the OBEX server may respond with a Connectresponse packet containing a response code indicating the failure ofthe connection.5. (Assuming successful authentication of the OBEX client by the OBEXserver), the OBEX client receives the Connect response packet, and284OBEXextracts the authenticate response from the OBEX server. It thenattempts to verify the authenticity of the OBEX server.
If this succeeds,the OBEX session has been connected.Connection failure cases Aside from authentication failures, there areother reasons why a Connect command may fail. For example, someclient applications or server applications will only work if connected to a‘strict peer’ – that means the Target header specified by the OBEX client ina Connect command matches the Who header associated with the OBEXserver that processes the Connect command. When such a failure caseis encountered, the OBEX client can abandon a Connect command bydisconnecting the OBEX transport. The OBEX server can refuse a Connectcommand in two ways:• send a response packet with a non-success response code.• disconnect the OBEX transport.DisconnectThe Disconnect command is used by the OBEX client application to closedown an existing session with an OBEX server. A Disconnect commandwill always comprise a single request–response exchange.
When theOBEX client application performs a Disconnect command, the OBEXclient sends a Disconnect request packet. Upon receiving this, the OBEXserver can send back a Disconnect response packet (which must alwaysindicate successful disconnection), or can simply disconnect the OBEXtransport to complete the command.PutThe Put command is used by the OBEX client application to transfer anobject from the OBEX client to the connected OBEX server. The OBEXclient application specifies the object to be sent, and the OBEX clientperforms the necessary processing to convert this into a sequence ofrequest–response exchanges.
A Put command can be completed in asingle request–response exchange, but this depends upon the size of theobject being transferred and the maximum OBEX packet size that theOBEX client is capable of sending and the OBEX server is capable ofreceiving.Most Put commands will require more than one request–responseexchange. The OBEX client uses the final bit in the request opcode toindicate the final request packet of a given Put command so that theOBEX server can complete the object transfer (e.g., commit the receiveddata to file) and prepare itself to accept the first request packet of the nextcommand from the OBEX client (see Figure 10.1).OBEX OVERVIEW285GetThe Get command is used by the OBEX client application to requestthat the connected OBEX server transfers a specified object to the OBEXclient.
The Get command is a little more complex than the Put command,as it has two distinct phases.In the first phase, the OBEX client sends a ‘specification object’ to theserver. In the second phase, the OBEX server sends an object, whosecontent is dependent on the specification object, back to the OBEXclient. The phases of a Get command should not be confused with therequest–response exchange of packets; both phases of the Get may consist of several request–response exchanges of packets as illustrated inFigure 10.3.Device with OBEX ClientOBEX Client applicationTraffic "on the air"OBEX ClientDevice with OBEX ServerOBEX ServerOBEX Server applicationGet command()<Specification Object>Get request packet()<Specification ObjectHeaders>Get response packet()Get request packet()Specification Phase<Specification ObjectHeaders>Get response packet()(Final) Get request packet()<Last of SpecificationObject Headers>Get command notification()<Specification Object>Object to be sent in response()(Final) Get response packet()Response Phase<Response ObjectHeaders>,response code "Continue"(Final) Get request packet()(Final) Get response packet()Get command completion()<Response Object><Last of ResponseObject Headers>,response code "Success"Figure 10.3 (Symbian OS-based) simplified view of OBEX Get command286OBEXIn the first phase, the data flows predominantly from the OBEX clientto the OBEX server in the request packets, which, as always, are acknowledged by the OBEX server returning response packets.
In the last requestpacket to contain specification object data, the OBEX client sets the finalbit to indicate that the first phase is over.Upon receiving the request packet with the final bit set, the OBEXserver completes the specification object transfer, and decides on theobject to be sent back to the client – this decision is entirely dependenton the service being used by the client and offered by the server. Thesecond phase commences, and the data now flows predominantly fromthe OBEX server to the OBEX client in the response packets. Effectively,during this phase, the OBEX client acknowledges the response packets bysending further Get request packets, until the OBEX server sends a finalresponse packet with the Success response code, and prepares itself forthe first request packet of the next command from the OBEX client. Uponreceiving the response packet, the OBEX client can complete the objecttransfer, for example, commit the received data to file.SetPathThe SetPath command is used by the OBEX client application to navigatethe directory structure on the OBEX server.
This directory structure willoften map directly onto a real file system, but can also be used for virtualdirectory structures that describe different areas of a given service, forexample, IrMC or the Bluetooth Phonebook Access Profile.A SetPath command will always consist of a single request–responseexchange. The OBEX client application determines the folder to moveinto, and encodes this into the request packet, along with flags whichindicate whether to ‘back up’ a level first, and whether to create a namedfolder if it doesn’t currently exist.
Upon receiving the request packet,the OBEX server will attempt to move to (and, if requested, create) thespecified folder, before sending back a response packet with a responsecode indicating the success or failure of the SetPath command.Note: the OBEX specification also indicates a defined XML format forfolder listing objects that can be used on request to pass informationon the folder structure of an OBEX service to the OBEX client. Thisformat has been used in the OBEX FTP server example code.AbortThe Abort command is used by the OBEX client application to abandonan ongoing command without taking the drastic step of disconnectingthe OBEX transport.
It is treated as a special case in the OBEX protocol,as an Abort request packet can be sent by the OBEX client instead of aOBEX OVERVIEW287request packet that continues an ongoing OBEX command. Upon receiptof an Abort request packet, the OBEX server will abandon any ongoingactivities associated with the current command. It will then send back anAbort response packet, and prepare itself for the first request packet ofthe next command from the OBEX client.10.1.5 OBEX TransportsOBEX packets need a means to move between the OBEX client and theserver. The means by which the packets are moved is known as the OBEXtransport, and a particular instance of a connection established over anOBEX transport is known as an OBEX transport link.OBEX can be run over many transports.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
