Symbian OS Communications (779884), страница 57
Текст из файла (страница 57)
The subject of finding and connectingto OBEX services in this way will be discussed in section 10.1.5.10.1.3 OBEX PacketsTo perform an OBEX transfer, the various headers described above have tobe placed into and (following transmission) extracted from OBEX packets.OBEX OVERVIEWDevice with OBEX ClientOBEX Client application279Device with OBEX ServerTraffic "on the air"OBEX ClientOBEX ServerOBEX Server applicationSet service Who()<Who value>Connect command()<Target Header>Connect request packet()<Target Header>Connect response packet()Connect command completion()<Connection ID Header>,<Who Header>Connection notification()Put command()Put request packet()<Connection ID Header>etc...Figure 10.2 (Symbian OS-based) example of use of Target, Connection ID and Who header in directedconnectionsThe OBEX specification defines formats for a number of different packettypes.
They can be divided into request packet types, which are sent fromthe client to the server; and response packet types, which are sent fromthe server to the client.Request packet formatAll request packets have the format shown in Table 10.2.The opcode field indicates the type of request that the OBEX clientis requesting from the OBEX server. The OBEX specification defines anopcode for each of the six OBEX commands (Connect, Disconnect, Put,Get, SetPath, Abort).
The most significant bit of the opcode field is termedthe ‘final’ bit, which is used in a command-specific way to signal the endof the current command, or the end of a phase of the current command.The packet length indicates the total length of this packet, including theopcode field and the length field itself. As a consequence, the minimumlength possible is three bytes, and the maximum length possible is65,535 bytes (216 – 1). Other factors may limit the usable packet size,and this is discussed later in this section, and in section 10.2.5).Table 10.2 OBEX request packet formatByte 0Bytes 1–2Bytes 3–nOpcodePacket lengthAdditional request data and/or headers280OBEXThe final part of the request packet contains any additional request datarequired by the particular OBEX command, and the headers themselves.In practice, only the Connect and SetPath commands require additionalrequest data.• For the Connect command, additional request data is used to communicate the OBEX version number, a flag byte and most importantlythe OBEX packet length that can be received by the client.• For the SetPath command, additional request data is used to communicate flags related to navigation and creation of directories on theOBEX server.Response packet formatAll response packets have the format shown in Table 10.3.The response code field provides a means by which the OBEX servercan communicate the outcome of the most recently received request fromthe OBEX client.
There is a wide range of codes defined in the OBEXspecification (based on HTTP status codes). Some represent successfuloutcomes (e.g., ‘Success’, ‘Created’, ‘Accepted’), some represent unsuccessful outcomes (e.g., ‘Bad Request’, ‘Forbidden’, ‘Unauthorized’), andsome are informational and may indicate success or failure dependingon context (e.g., ‘Partial Content’). Again, the most significant bit of theresponse code field is termed the ‘final’ bit, and is used in a commandspecific way to signal the end of the current command, or the end of aphase of the current command.The meaning of the packet length field is identical to that of the packetlength field in the request packet.The final part of the response packet contains any additional responsedata required by the current OBEX command, and the headers themselves.In practice, only the Connect response contains additional responsedata – it is used to communicate the OBEX version number, a flag byteand most importantly the maximum OBEX packet length that can bereceived by the server.Packet sizesAs mentioned above, although the maximum packet size is limited to216 – 1 by the size of the packet length field, other factors can affect theTable 10.3 OBEX response packet formatByte 0Bytes 1–2Bytes 3–nResponse codePacket lengthAdditional response data and/or headersOBEX OVERVIEW281usable size of an OBEX packet, since the actual maximum packet size isnot known until the Connect command is complete.The most common factor is the capability of the peer OBEX device.Some devices or implementations of OBEX may have limited buffer spaceinto which an OBEX packet can be received.
During processing of aConnect command, the OBEX client and server exchange details of themaximum OBEX packet length they can each receive. If the connectionis accepted, the OBEX client must respect the maximum packet length ofthe OBEX server, and the OBEX server must respect the maximum packetlength of the OBEX client.The minimum allowable value for the maximum packet size is255 bytes; this is also the default maximum packet size used whenprocessing a Connect command, before the maximum packet size of theremote device is known.In practice, the packet size tends only to affect the performance of anOBEX transfer.
If the allowed packet size is very small, however, it mayprevent some headers from being transferred entirely – headers may notbe fragmented between OBEX packets.2Header encodingHeaders may be encoded into the space in a packet following the opcodeor response code field, packet length field and additional request orresponse data. An OBEX client or server attempting to transfer an objectwill attempt to use as much of the available space in a packet as possibleto transfer headers (assuming there are headers to transfer).Because the size of the OBEX packets is limited, not all headers willfit into one request packet and so must be sent in consecutive packetsbelonging to the same command.
There are few rules governing the orderin which headers are sent, but generally the headers will be prioritized asfollows:1. Non-object model headers2. Object model headers other than Body/End of Body3. Body/End-of-Body headers.10.1.4 OBEX Session ProtocolAs mentioned above, the OBEX session protocol defines a structureddialog where a client sends request packets to a server, after whichthe server sends response packets to the client. This exchange proceedsin strict rotation, request–response, request–response until the required2Strictly speaking, even Body headers are not fragmented between OBEX packets;rather, the payload of an object is fragmented into multiple individual Body headers.282OBEXtransfer or transfers are complete.
The following sections summarize thepacket exchanges involved for each OBEX command.ConnectThe Connect command is used by OBEX client application to establish asession with an OBEX server. The Connect command must therefore beused before any other OBEX commands for a given session.3A Connect command will comprise either a single request–responseexchange, or two request–response exchanges, depending on whether theclient, or server, or both client and server, are requesting authentication.Whether authentication is required or not is an application-specificdecision.
The various authentication scenarios are described below.Connect (no authentication)The sequence of events is as follows:1.The OBEX client sends a Connect request packet to OBEX server.2.The OBEX server receives the Connect request packet.
It then preparesand sends a Connect response packet to the OBEX client.3.The OBEX client receives the Connect response packet.Connect (client authenticates server) The sequence of events is asfollows: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, and extractsthe authenticate challenge header. It then prepares and sends aConnect response packet to the OBEX client. The Connect responsepacket contains an authenticate response header (preparation of theauthentication response header often involves accepting user inputof a password).3.The OBEX client receives the Connect response packet, extracts theauthenticate response header and verifies the authenticity of theOBEX server.
If the authentication is successful, the OBEX clientwill proceed with further OBEX commands. If the authenticationis not successful, the OBEX client may proceed with a Disconnectcommand or simply disconnect the transport.Connect (server authenticates client)1.The OBEX client sends a Connect request packet to the OBEX server.3This is not strictly true; there are variations of OBEX that are not connection oriented(e.g., OBEX over IrDA Ultra), but the vast majority of applications of OBEX use theconnection-oriented version.OBEX OVERVIEW2832. The OBEX server receives the Connect request packet. It then preparesand sends a Connect response packet to the OBEX client with theresponse code value ‘Unauthorized’ and an authenticate challengeheader originating from the OBEX Server.3.
The OBEX client receives the Connect response packet, and extractsthe authenticate challenge header. It then prepares and sends asecond Connect request packet similar to its first, but this timeincluding an authenticate response header.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
