.NET platform mobile phone management software development (5) - OBEX introduction

xiaoxiao2021-03-06  47

(5) OBEX introduction

First, what is Obex, what is the purpose?

Obex is all called Object Exchange, Chinese object exchange, so it is called an object exchange protocol. It has a core status in this software, file transfer and IRMC synchronization use it.

The OBEX protocol is built on the upper layer of the IRDA architecture.

The OBEX protocol implements easy, efficient exchange information between different devices, and different platforms, and different platforms. Supported equipment, such as PC, PDA, telephone, camera, automatic answering machine, calculator, data collector, watch, etc.

The Obex protocol defines a flexible concept - Objects. It is also an object. These objects can include files, diagnostic information, e-commerce cards, bank deposits, and more. Objects There is no advanced technical meaning here, but is dependent on your application.

The OBEX protocol is small to the "command and control" function, such as the operation of the TV, video recorder, etc. Avenue can do a complex operation, such as transaction processing and synchronization of the database.

Obex can have the following features:

1. Friendly application - fast development.

2, tightening - available on small devices available in resources.

3, cross-platform

4, flexible data support.

5. It is convenient to serve as an upper protocol of other Internet transport protocols.

6. Scalability - provides expansion support for future demand without affecting the existing implementation. For example, expandable security, data compression, etc.

7, can test the debugging.

For more specific information about Obex, please consult the IROBEX protocol.

Second, OBEX object model

About Headers

The object model answered how the object is described in the OBEX protocol. This model must include the transmitted object and a description of the object. In order to do this, Obex defines the concept of Headers.

A header reflects one aspect of the object, such as name, length, description text or object itself. For example, a file object demo.txt will contain its name, a type labeled "Text", length, and file itself.

HEADERS composition

Headers is simple from

and
, referred to as and .

Hi consists of one byte, pointing out the contents of the header and its format. The HV contains one or more bytes, and its structure is determined by Hi.

All headers are optional, depending on the type of the device and the type of transaction. You can use all headers, or some, or not. The ID can make the header resolution and the transmission order, or the unsupported header can be ignored.

Hi can be divided into two parts, high 2 and low. The high 2 bits determine the Hi encoding mode (see Table 2), and the low 6 bits determine the meaning of Hi (see Table 3). Both tables are the excerpse of IROBEX and partially translated.

Table II

Hi's 8th and 7th

significance

00 (0x00) The Unicode text ending with NULL (0x00). Two bytes of unsigned integer length prefixes. 01 (0x40) BYTE block, 2 bytes of unsigned integer prefixes. 10 (0x80) 1BYTE capacity. 11 (0xc0) 4BYTE capacity, with a high-level transfer as principle.

Table three

Hi

HEADER name

description

0xc0 COUNT connection The number of name objects is used. 0x01 Name object's name. Generally a file name. 0x42 Type object type. For example, Text, HTML, Binary, Manufacture Specific 0x44 0xc4 Time Timestamp. ISO 8601 version timestamp. 4Byte version (for compatibility) 0x05 Description to object's text Description 0x46 Target Operation Delivery Service Name 0x47 HTTP A http1.x head 0x48 body object part 0x49 End of body object's last part 0x4a

The Who Obex Application ID is used to indicate whether it is the same application. 0xCB Connection ID Digzy 0x for Obex Multi-Diven Connection

4C

App.Parameters extended application layer request and reply information 0x4d auth.challenge authentication Digest-challenge 0x4e auth.response authentication Digest-response 0x

4f

Object Class object OBEX object class 0x10 to 0x

2F

Reserved reserves 0x30 to 0x

3F

User defined users are customized.

For more detailed explanation about common header, please refer to IROBEX more detailed information.

1. Name Name is a Header used to describe the name of the object, consisting of Unicode strings ending with NULL (0x00). For example: Demo.txt

2, Length Length describes the size of the object, consists of 4 bytes. If Length knows in advance, this header should be used. This allows the recipient to quickly know how many spaces need to be assigned, which can make the process more quickly. But this is not necessary, in some cases, the length cannot be confirmed, but the device can be found through the end-body header to end.

3, TIME

Time describes the last modified time of the object. Use the ISO8601 format.

Local Time Format: YYYYMMDDTHMMSS

UTC time format: YYYYMMDDTHHMMMSSZ

Type T can be convenient to distinguish between date and time. UTC time uses Z as a mark. UTC time is recommended. 4, Body, End-of-Body

Body Header is described by Hi, a 2byte length and the entire object itself. End-of-body composition is the same as the body composition, but identify this is the last part of the object. If the object is very small, use end-of-body directly.

Third, request (Request) and response (response)

Obex uses Request and Response as the most basic operation. Each request for the request must have a response, otherwise it is considered that the request failed.

Request consists of one or more Packet (packets), each package structure is as follows

Request packet structure

Byte 0

Byte 1, 2

Byte 3 to n

Optographic Packet Length (Package Length) Headers or Request Information

Since each request may have multiple Packet, the highest bit of Opcode is called Final Bit. If set to 1, then this is the last packet of Request. For example: When sending a large file with the PUT operation, there will be several packets as a request. Then only the last packet FinalBit is set to 1.

Response is also consisting of one or more Packet, each package structure, as follows

Response packet structure

Byte 0

Byte 1, 2

Byte 3 to n

Response Code Response Length ResponseData responds to data

The highest level of the same responsecode is also called FinalBit. ResponseData may contain objects and headers, or other information.

The following table lists common OpCode and responsecode, please refer to IROBEX 1.2 documentation more detailed.

Opcode

Opcode (W / high bit set)

definition

significance

0x80 * connection 0x81 * disconnect disconnect 0x02 (0x82) PUT Send an object 0x03 (0x83) GET acquired an object 0x04 (0x84) reserved reserved 0x85 * setPath setting path 0xff * Abort Cancel current operation 0x06 to 0x

0F

Reserved as an extended reservation 0x10 to 0x

Allf

User definable user-defined

* Always set FinalBit

Responsecode

Responsecode

definition

0x10 (0x90) Continue (Continue) 0x20 (0xA0) OK, Success 0x40 (0xc0) Bad Request (server does not understand) 0x41 (0xc1) unauthorized (unauthorized) 0x43 (0xc3) FOBIDDEN (Disable-Server understand Request , But refused) 0x44 (0xc4) Not found (not found)

Fourth, instructions.

1, Connect (connection)

This initialization session then sets the parameters. Its REQUEST format is

Byte 0

Byte 1, 2

Byte 3

Byte 4

Byte 5, 6

Byte 7 to n

0x80 Package Length OBEX version flag The largest OBEX package length Optional HEADER

Note: The OBEX version is now 1.0.

The Response format is:

Byte 0

Byte 1, 2

Byte 3

Byte 4

Byte 5,6

Byte 7 to n

ResponseCode package length OBEX version flag largest OBEX package length Optional HEADER

For more information about Connect, please refer to IROBEX

2, disconnect (disconnected the current session)

This operation disconnects the OBEX session. For example, disconnect the current FolderListing Service, then connect to the IRMC Sync Service to the IRMC Sync Service to achieve functionality.

The disconnect format is:

Byte 0

Bytes 1, 2

Bytes 3 to n

0x81 package length Optional HEADER

Successful disconnection will return 0xA0, refuse to return 0xD3

3, PUT operation

The PUT operation sends an object to the server from the client. There is generally at least two headers with Name and Length. There may be Date / Time Header for documents.

The format of the PUT operation is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

0x02 (when FinalBit is set, 0x82) PacketLength Package Length Group of Header

The response format is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

Responsecode (required to continue to be 0x90; successful 0xA0) Package length Optional HEADER

More detailed usage of PUT operations will be explained in the file transfer portion.

4, get operation

The GET operation returns an object from the server. The format of the GET operation is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

0x03 package length a set of Header

The response format is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

Response Code Package Length Optional HEADER

More detailed use of GET operation will be explained in the file transfer portion.

5, ABORT operation

ABORT operation interrupts a multi-package operation (for example, sending a large file). The Abort operation can contain Description Headers describing the cause of the interrupt.

The format of the ABORT operation is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

0xff package length Optional HEADER

Abort should be a successful operation (0xA0) indicating that this operation has been received and the server has been re-synchronized with the client. If another value returned, the client should disconnect.

6, setpath

SetPATH operations for switching the path of the other party. Usually use a Name header to specify the counterpan name. If you are empty, return the default directory, usually rooted

The setPath operation format is as follows:

Byte 0

Bytes 1, 2

Byte 3

Byte 4

Bytes 5 to n

0x85 Package Length Flags Constants Optional HEADER

Note: Flags can set BIT0 and BIT1. Bit0 means returning to the last layer; Bit1 means that if the directory does not exist, create a directory, otherwise returns an error.

The response format is as follows:

Byte 0

Bytes 1, 2

Bytes 3 to n

ResponseCode Package Large Optional Response HEADER

V. Actual example Note: Data is obtained using SerialMonitor. The client is PC, the server is the Siemens M55 mobile phone.

1, Connect, Disconnect

ÇConnect Request:

80 00

1A

10 00 40 06 46 00 13 6B 01 CB 31 41 06 € .... @. F..k.ë

1A

.

11 D4

9A

77 00 50 Da

3F

47

Allf

.Ôw.pú? G.

Èconnect response:

A0 00

Allf

10 00 01 Da CB 00 00 01 00

4A

00 13 6b ..... úë .... j..k

01 CB 31 41 06 11 D4

9A

77 00 50 Da

3F

47

Allf

.Ë.

1A

..Ôw.pú? G.

ÇDISCONNECT REQUEST:

81 00 03 ..

ÈDisconnect response:

A0 00 03 ..

This example is first connected to the phone, then use Disconnect to detach.

ÇConnect Request:

80: Connect

00

1A

: Package length 26 bytes

10: OBEX version 1.0

00: Always 0

40 06: The maximum package length is 16390 bytes.

46: Hi, Target. The 0x40 starts, indicating the length description of the rear with 2 bytes.

00 13: HEADER length 19

6b ... .: Corresponding Target

Èconnect response: A0: OK, SUCCESS

00

Allf

: Package length 31 bytes

10: OBEX version 1.0

00: Always 0

01 Da: Maximum Package Length 474 bytes

CB: Connection ID = 0x100.0xc0 begins with the beginning of the back and 4 bytes.

4A

00 13: WHO Header. Length 0x13.

6b ...: who header value.

2, PUT, GET, SETPATH

Example 1: How to download 21680.mid files in the mobile / Sound directory. Size is 313 bytes.

The whole process is divided into:

Connection æ Switch to the root directory æ to switch to the Sound directory æget (21680.MID)

Specific process:

... (Connection part omit)

Ç switched to the root directory, name header (0x01) is empty

85 00 08 02 00 01 00 03 .......

È response

A0 00 03 ..

Ç switches to the / Sound directory. Name header (0x01) length 0x11.

85 00 16 02 00 01 00 11 00 53 00

6F

00 75 00 6e ........... S.O.U.N

00 64 00 73 00 00 .d.s ..

È response

A0 00 03 ..

Çget request. Name header (0x01) specifies the file name

83 00

1A

01 00 17 00 32 00 31 00 36 00 38 00 30 ƒ ......

2.1.6

. 8.0

00 2E 00 6d 00 69 00 64 00 00 ... m.i.d ..

È Response 0x90 Description Need to continue. 0xc3 Indicates File Length 00 00 01 39.0x48 Description is part of the file.

90 01

44 C

3 00 00 01 39 48 01

3C

4D ....

Çget request. Since the server returns 0x90, continue to send GET

83 00 03 ƒ ..

È responding. success. The server sends 0x49 description is the last part of the object.

A0 00 06 49 00 03 ..i ..

Example 2: How to get a big file, mainly introduce the GET section.

Obtain /Pictures/102725.jpg, size 5314 bytes.

The whole process is divided into:

Connection æ Switch to the root directory æ to the Pictures directory æget (102725.jpg) æget ....

Çget request. Name header value is 102725.jpg

83 00

1C

01 00 19 00 31 00 30 00 32 00 37 00 32 ƒ ...

1.0.2

.7.2

00 35 00 2E 00

6A

00 70 00 67 00 00 .5 ... j.p.g ..

È Return a body. Client should continue to send GET

90 01 D

3 c

3 00 00

14 C

2 48 01 CB FF D8 FF E0 00. Óã ... "ëÿÿøÿà.

10

4A

46 49 46 00 01 01 01 02 58 02 58 00 00 ff .jfif ..... x.x..ÿ .....

Çget request.

83 00 03 ƒ ..

È Return the second body. Client continues to send Get

90 01 D7 48 01 D4

6A

60 99

1C

A2 74

4C

92 67 bc. × H. ôj`TM. ¢ TL'G4

A9 AA 84 CD 6B 20 83

83 f

4 BB DF 8B BC

58 A

4 DC © ª "ík ƒƒƒƒ» ß <1/4x¤

............ (omitted a number of repetition processes)

Çget request. Since the server returns 0x90, continue to send GET

83 00 03 ƒ ..

È responding. success. The server sends 0x49 description is the last part of the object.

A0 00 06 49 00 03 ..i ..

Example 3: Send a file to /sound/1.mid. Size 313 bytes

The whole process is divided into:

Connection æ Switch to the root directory æ to switch to the Sound directory æPutæ ...

Specific process:

... (omitting the connection switching section)

Çput operation

0x82: PUT operation, FinalBIT settings

0x01: nameheader. File name 1.MID

0xc3: Length. File size

0x44: Date and time. Here

2005

year

2

month

14

day

19: 49: 38. Use local time.

0x49: End-of-body. The last part of the file.

82 01 65 01 00

0F

00 31 00 2E 00 6d 00 69 00 64, .e ... 1. 1 ... m.i.d

00

00

C

3 00 00 01 39 44 00 12 32 30 30 35 30 32 .. ã ... 9d..200502

31 34 54 31 39 34 39 33 38 49 01

3C

4D 54 68 64 14T194938i.

È response

A0 00 03 ..

Example 4: Send files to /Pictures/102725.jpg, size 5314 bytes.

The process is divided into:

Connection æ Switch to the root directory to switch to / Pictures directory æputæ ...

Specific process:

... (omitting the connection switching section)

Çput operation

0x02: PUT operation, Fianlbit is not set. Note The remaining part needs to be sent.

0x01: nameheader. File name 102725.jpg

0xc3: Length. File size

0x44: Date and time. Here

2005

year

2

month

14

day

, 19: 57: 52. Use local time.

0x48: body. Part of the file.

02 01 D0 01 00 19 00 31 00 30 00 32 00 37 00 32 ..ð ....

1.0.2

.7.2

00 35 00 2E 00

6A

00 70 00 67 00

00

C

3 00 00 14.5 ... j.p.g..ã ...

C2 44 00 12 32 30 30 35 30 32 31 34 54 31 39 35 â 20120050214T195

37 35 32 48 01 9D FF D8 FF E0 00 104A

46 49 46 752h. Ÿøÿà..jfif

......

È responding. Client continues to send

90 00 03

Çput operation

0x02: PUT operation, Fianlbit is not set. Note The remaining part needs to be sent.

0x48: body. Part of the file.

Note: Do not set an extra Header.

02 01 D4 48 01 D

1 f

3 C

0 f

1 2D

5A

E9 98 B1 1B 71 ..ô.ñóàñ-zé ~ ± .q

47 96 5B 45 30 BD

3C

7e 2b D7 AE 82 6B DF

2C

42

G

- [E0/2 <~ × × ®, Kß, B

B5 BA 21 D3 6B 16 B5 B8 DB

4F

D4 23 DB

11 C

6

4C

μo! ók.μ ûûoô # û.æl

......

... (omitted a number of repetition processes)

Çput operation

0x82: PUT operation, FinalBit settings. Description This is the last part

0x49: End-of-body. The last part of the file.

82 01 22 49 01

Allf

F6 75 BF 01

3C

02 49 48 E4 48,. "I..öu. <. Ihäh

6f

3E FF 00 2D 51 25 CF 32 D8 39

5F

25 D8 88 44 o> ÿ.-q% ï2ø9_% ØD

... ..

È responding. success

A0 00 03

转载请注明原文地址:https://www.9cbs.com/read-58456.html

New Post(0)