OBEX 4. OBEX Application Framework

生也有涯,知也无涯。这篇文章主要讲述OBEX 4. OBEX Application Framework相关的知识,希望能为你提供帮助。
The OBEX application framework is a set of conventions and services designed for the purpose of
creating interoperable(互操作性) devices. OBEX is a very flexible protocol and the application framework tightens up(加强了)the usage of OBEX while creating a set of standard services that satisfy(满足) many object exchange needs. The foundation(基础) of the OBEX application framework is the Default OBEX Server.
OBEX application framework 是一些service。这些service提供了设备的互操作性。OBEX是很灵活的协议,满足了数据交换需求的同时,又加强了它的用途。基础的OBEX application framework就是默认的OBEX server。
4.1 The Default OBEX Server
The Default OBEX Server is the server that resides at the LSAP-Sel specified by the IAS entry with class
name “OBEX” (see section 6.1 IAS entry for details on this IAS entry). The Default OBEX server is the
“Well Known” OBEX server. All the standard services along with many applications are accessed via this
server including IrMC applications. For general device to device interoperability the default OBEX server
is used. There can only be one entity registered to be the default OBEX server. If more than one exists it
will be impossible(不可能) for another device to distinguish(区分) between the two.
The default OBEX server can be used to access file systems, databases, services and applications.
OBEX provides conventions for distinguishing(区分) the types of accesses. The Name, Type, Target and
Connect Id headers can be used for this purpose. The most basic service accessed via the default
OBEX server is the inbox service.
默认OBEX server处于LSAP-Sel一端。默认OBEX server是众所周知的OBEX server。所有的标准服务和许多应用程序都可以通过这个服务器访问,包括IrMC应用程序。对于一般设备到设备的互操作性,使用默认的OBEX服务器。只能有一个实体注册为默认的OBEX服务器。如果存在不止一个,那么另一个设备就不可能区分这两个。默认的OBEX服务器可用于访问文件系统、数据库、服务和应用程序。OBEX提供了区分访问类型的约定。“名称”、“类型”、“目标”和“连接Id”标头可用于此目的。通过默认OBEX服务器访问的最基本的服务是收件箱服务。
4.2 The Inbox Service
The most basic form of object exchange is pushing a file/object to another device. The sending device
(client) is only responsible(负责) for making sure the object is transferred correctly. The client does not know or care what happens to the object after it has been received. The receiver (server) is responsible for
placing the object in the correct location. This basic from of file transfer is accomplished with the OBEX
PUT operation. The client does not need knowledge of the server’s object store or folder hierarchy. The
client initiates the operation by sending the object to the default OBEX server. When pushing an object, a
Name header is used to name the object and a Type header may be used to identify the type. Other
headers such as Length and Time can be also sent.
OBEX的最基本功能就是在设备间交换文件或者object。发送方,只负责把数据完整无误地发出去。发送方不知道也不关心数据发送过去后发生了什么。接收方负责把object放到正确的位置。使用PUT完成文件传输。发送方不需要知道server把这个文件存在哪里,以及server的文件夹构成。
In this simple form of object transfer, the object is pushed into the server’s “inbox”. Inboxes come in many
forms. A PC based application could have a folder in the PC’s file system, which represents the inbox.
But, an inbox does not necessarily have to be a fixed folder or location. It is also possible to dispatch the
object based on the Type header or the extension(扩展) in the Name header to a more appropriate(合适的) location such as an application or database. Products, which do not have a file system, can operate in this way. The structure of the inbox is an issue strictly(严格地) for the server. The client simply pushes objects to the “inbox”. What happens after that is up to(取决于) the server. The push model works best for single objects. It can also be used for moving whole folder/directory hierarchies.
简单的传输格式是object被压入server的inbox里。inbox有多种形式。基于pc的app的inbox就是pc里的一个文件夹。但是这个文件夹不必须要在哪个固定的位置。有的inbox也可以是app或者数据库,通过使用type header或者name header来指定。尤其适用于没有文件系统的制品。server的inbox的结构严格地说是一个问题。client只是简单把object发送给server,之后会发生什么完全取决于server。push model在单个object上工作的很好。它也可以用于移动文件夹。
It is important to note that what may be an application specific(特定的) object for one device is just a file in another device. Thus(因此), it is important that all devices standardize on using the default OBEX server for performing this simple operation. In this way, interoperability(互操作性) is more likely to occur. The capability service is also used to help increase the interoperability for simple object pushing. Refer to chapter 8.2 Simple OBEX Put file transfer (+ SetPath) for more information on the Inbox model.
需要注意的是,一个设备的特定于应用程序的object只是另一个设备中的一个文件。因此,所有的设备都使用default OBEX server来进行通信。只有这样做,才有好的互操作性。capability service用于提高简单object push。
The Inbox service also enables a device to GET certain objects from another device without
understanding(理解) the semantics(语义) of the service or database that contains the object. This is called the default GET and is intended for use with a narrow band of object types that have a default object. A vCard is a good example of an object type that has a default object.
inbox service也支持,对端在不需要知道服务的service或database是具体如何存储object的情况下,也可以GET一个特定的object。这种行为叫做default GET。特别用于窄带宽类型的default object。vCard就是窄带宽类型的default object的代表。
4.3 Inbox Connection
The inbox is accessed via an OBEX connection called the “inbox” connection. This connection is made to
the default OBEX server by sending a CONNECT command with no Target headers. Objects sent using
Ultra are placed in the inbox but in this case the CONNECT command is not used. Other services are
also accessed via the inbox connection. These services all have specific characteristics that allow an
implementation to distinguish between the different service requests. The table below gives the complete
list of services available via the inbox connection along with the distinguishing characteristics.
inbox通过OBEX connection来访问,这个连接叫做 “inbox” connection。这个连接用于连接default OBEX server,通过CONNECT操作而且不带Target headre。使用ULtra发生的对象被放置在inbox中,但在这种情况下,不使用CONNECT操作。其他的service也可以通过 inbox connection来访问。这些service有专用的字符串,以让实现来区分。下表列出了通过 inbox connection访问的service和区分的字符串。

Service type Service description
Capability Service The capability object is accessed by using a GET command with a Type header containing the MIME type of the capability object, “x-obex/capability”.通过GET访问capability object时,需要使用type header,值为“x-obex/capability”
IrMC Level 2 and 3 Level 2 and 3 services of the IrMC application are accessed using PUT and GET commands with a Name header in which the first part the name contains “telecom/”.通过GET和PUT可以访问level 2和3的IrMC application,需要使用name header,值开头部分必须包括“telecom/”
Pushing objects into the inbox Objects are pushed into the inbox by using the PUT command with a Name header. The string in the Name header should not contain any path characters such as ‘:’, ‘/’ or ‘\\’. Objects with improperly(不恰当的) formed names should be rejected。压入到inbox的object必须使用name header,而且值里面不允许有\':\',\'/\',\'\\\'。有的话就会被拒绝。
Pulling objects from the inbox Default objects are pulled from the inbox by using the GET command with a Type header containing the MIME type of the desired object. Name headers are not allowed.通过GET从inbox里拿数据时,必须包含type header,来指出你想要的object。name header不允许有。
4.4 Capability Service
The OBEX capability service is designed to provide a general-purpose method for accessing service
information with OBEX. The capability service lists the type of objects supported and details about the
fields or formats of specific types. A client may be able to render(render into:渲染成) an object into multiple formats. By reading the server’s capability object the client can determine the best format to send the object. The client can also determine if it makes sense to even send an object at all(究竟:at all).
OBEX capability service可以提供service的详细信息。capability service 可以返回一个列表,里面有被支持的object的类型和object字段和格式的详细信息。client可以把一个object渲染成多种格式的object。client通过读取server返回的capability object列表,就可以得知这个service要使用的object格式,所以client就把object渲染成service想要的格式。client还可以判读出发生一个object究竟是否是合理的。
The capability service is based upon(基于) two OBEX objects, the capability object and the object profile object.The capability object contains general-purpose information about the device, including the services and applications that are supported. The object profile object contains information specific to the objects that the device supports. The details of the capability service and its objects can be found in sections 8.5
Capability Service, 9.3 The Capability Object and 9.4 The Object Profile Object
capability service基于2个object,一个是capability object;一个是object profile object.capability object里存放的是设备的基本信息,包括设备支持是service和application等信息。object profile object里包含此设备支持的object的信息。 capability service和它支持objects的详细信息在,8.5, 9.3, 9.4章节可以找到。
4.5 Custom OBEX applications
OBEX can also be used as a protocol within custom applications, providing the basic structure for the
communication. In this case, the application may set the OBEX IAS hint bit, but it must not use the OBEX
IAS entry. Instead, the custom application should define its own unique IAS entry.
While(虽然) a custom application will (by definition) work best when connected to a strict peer, there are cases where it may be useful to connect to the default OBEX server. In particular(尤其), if a custom application can send any objects of general interest but cannot find a peer application, it could send the data to a default OBEX server inbox, perhaps modifying the sending format to be a common computer format such as text, GIF, JPEG, or such.
For instance, a digital camera could look for digital film development kiosks, but also want to share
photos from last summer’s camping trip with any PC, PDA, or smart TV. A pager might delete messages
automatically after sending them to its peer application (knowing they are completely taken care of), but send them as text objects to any OBEX enabled device just for easy viewing or sharing. Any IR device
whatsoever(不管怎样) might offer its “business card”, describing who and what it is.
OBEX可以作为app之间的协议,提供app之间通信的基本结构。app可以设置自己的OBEX IAS hint bit,但不可以使用OBEX IAS entry。app应该定义自己专用的OBEX IAS entry。虽然自定义应用程序在连接到严格对等的对方时,工作得最好,但在某些情况下,连接到默认的OBEX服务器可能会很有用。尤其,一个自定义的app发生了一些object,但是找不到对等的peer app,它就可以把object发送给default OBEX service inbox,可能需要修改数据的格式,必须修改成text,GIF,JPEG等格式。
例如,数码相机需要找一个能打印照片的的机器(在便利店里),但也有需求把照片传到PC等设备。任何红外设备都会提供它的 “business card”, 来告诉别人它是谁。
4.6 Directed Operations and Connections
A directed operation is an operation that is sent toward a specific service. An OBEX Target header is
used to identify the designated service. If the receiving side has a matching service, all packets in the
request are forwarded (or re-directed) to that service. In addition, a Who header is sent in the response to
indicate that the request is being serviced by the requested service. If a matching service cannot be
located, the server is encouraged to accept the request if at all possible. This allows the client to make
the final decision on whether to continue the operation or abort. In this case a Who header is not returned
in the response. When the operation is complete, the association is dissolved(终止). If the client wishes to direct another operation to the service it must again include the Target header. This is where directed
connections come in handy(排上用场:come in handy).
定向操作是跟一个特定的设备通信。使用Target header来指明它像要和哪个service通信。如果接收端有匹配的service,所以的request data都会传个那个匹配的service。另外,service返回的response里会包含who header,以告诉请求端,你的请求我服务了。如果sever里没有client用Target header指定的service的话,server也最好处理这个请求,告诉client没有你要的server。最后让client决定是否继续请求还是放弃。在这种情况下server返回的response里没有who header。如果client还要请求别的service,则再次发送包含Target header的请求。这就是定向连接排上用场的地方。
Directed connections enable a client and server to establish a virtual connection based on the principles(规则)of directed operations. They exist for clients that need to perform multiple operations to a specific service. Once a directed connection is established, the client can direct operations to the same service by simply including the Connection Id header in each request. A directed connection is initiated when a client sends an OBEX CONNECT packet with a Target header containing the UUID of the service it wishes to connect to. A successful match is indicated with a Who header in the response packet as well as a
Connection Id header. The Connection Id header contains the identifier of the connection that the client
will use in future requests as shorthand for a Target header
基于定向连接操作,定向连接可以让client和server建立一个虚拟连接。这个虚拟连接可以让多个client请求一个特定的service。一旦定向连接建立后,client就可以非常容易地和server通信了,只需在请求里包含connection id header即可。当client在CONNECT操作里包含里Target header,就会建立定向连接。如果server返回的response里包含who header和connection id header的话,则说明定向连接建立成功。有了定向连接,client后续的请求了只需包含connection id header即可。
4.6.1 Directed Connection MechanicsDirected connections do not follow the usual paradigms(范例) one would associate with a “connection”. It is recommended that directed connections always be “open”. Therefore, it is unnecessary to close a
connection with an OBEX DISCONNECT operation. In essence(实质上), a directed connection provides a
shortcut so the client doesn’t have to specify a Target header in every operation. As well as(以及,也) providing insurance(保险) that the designated(想要的) service will receive the clients requests.
It is not necessary to track the open or closed status of directed connections. Therefore OBEX
CONNECT operations should not be reference counted and matched with OBEX DISCONNECT
operations.
由于定向连接一直是open的状态。因此没有关闭定向连接的必要。实质上,定向连接提供了一个捷径,让client不需要指定Target header在每次请求里,也保证想要的service会接收到client的请求。没有必要去跟踪定向连接的open或者close状态。因此OBEX CONNECT operations 不需要被计数,不需要别关闭。
It may or may not be necessary for a server to differentiate(区分) an operation that arrives with a Connection Id from one that arrives with a Target header for the same service (other than making sure to respond with the Who header). This is unlikely(不大可能) to be an issue(问题) in normal implementations but it should be noted that the acceptance(接纳) of a directed connection by a service, does not guarantee(保证) that another operation sent with a Target header to the same service will be accepted by that service. It is anticipated(令人期盼的) that CONNECT operations that are intended to establish directed connections will contain the same flags, OBEX packet size and protocol versions as did all previous CONNECT operations. Handling of CONNECT options that differ from original or previous values is implementation dependent.
可能没有或有必要区分一个操作是带着 Target header,还是带着Connection idheader。在通常情况下,这可能不是问题,但是必须要知道,当建立定向连接后,发送过来的请求了包含了Target header,则这个请求有可能不被接收处理。未来如果能在CONNECT operations里包含上次连接的所以相同的信息,比如packet size,协议版本号等,那就最好不过了。
4.6.2 Target Header ProcessingIn some cases, more than one Target header may be present in a request. The server should match the
headers in the order received and ignore any Target headers encountered after a match is made. The
matching header is then sent in the response Who header.
在一个请求里可能包含多个Target header。服务器应按接收的顺序匹配头,并忽略匹配后遇到的任何目标头。然后在响应里包含匹配的who header。
4.7 OBEX Access Methods
Since(由于) not all objects are the same, there arises(出现) the need to define methods for accessing different types of objects. This section defines sets of standard procedures or templates for each type of access. Three basic forms of access have been identified: File, Database and Process. Interoperability will become easier when, for example, accessing a database all clients follow the same basic procedures. Of course, the values in the headers and such will differ for each database but the basic procedure should be the same.
由于并非所有的object都是相同的,所以要根据不同类型的object定义不同的访问方法。这里定义访问每种object的标准流程或模板。有3种格式被定义:文件,数据库,进程。当大家遵循标准流程,互操作性就变得简单易行。虽然header里要访问的不同的数据库,但是访问数据库的流程是一样的。
4.7.1 File AccessFile level access is the lowest level of object access provided by OBEX. Using file level access an object
can be retrieved(检索) and stored only as a whole. It relies on(依赖) addressing(寻址) an object by providing a Name and optionally a Type header. The Name header identifies the instance of the object. This is often sufficient(足够的) when sending an object. The Type header is used to refine(精炼) the objects identification when multiple objects may exist with the same name.
文件访问是最低级别的访问。使用文件级访问,对象只能作为一个整体进行检索和存储。它依赖name header和可选的type header来寻找object。通常name headre就能够唯一标识出要找的object。当objects是同样名字的时候,就需要type header来辅助提供更精确的信息,以便找到所需的object。
4.7.2 Database AccessA database is different from a file system. The objects manipulated(操纵) in a file system tend to be course blobs. While the items in a database are more refined. Often, the individual fields and records can be manipulated in a database. Whereas(虽然) many different types of objects are stored in a file system,
databases tend to store or organize(组织) objects of a similar nature.
数据库和文件系统不同。在文件系统里的object是整块被操作的。而数据库会更细致,独立的字段或者一行数据都可以被操作。虽然许多不同类型的对象存储在文件系统中,但数据库倾向于存储或组织性质相似的对象。
OBEX database level access allows for finer(更精细) granularity(粒度) access to objects. Objects accessed using database level headers can be manipulated by part. In other words pieces of a database object can be requested and stored instead of having to exchange the entire object. Database access relies on a Name header to identify the instance of the database object. In addition, OBEX has an Object Class header, which is designed for use with database objects.
访问数据库的object可以按部分访问。换句话说,一个数据库object可以分块请求和存储,而不必像文件那样,必须作为一个整体存储。数据库访问依赖name header,name header指明要访问的object。另外OBEX有Object class header,它可以和数据库object一起使用。
4.7.3 Process / RPCIn interacting(相互作用) with a process, the actual information transferred is generated and consumed on the fly. The best example is the Synchronization(同步) command interpreter(解释程序) in the IrMC specification(规范). The items being PUT are often commands and not objects.
和进程交互,实际的数据都是动态生成和消费的。最好的例子是IrMC规范中的同步命令解释器。正在PUTING的不是object而是命令。
c/c++ 学习互助QQ群:877684253 本人微信:xiaoshitou5854【OBEX 4. OBEX Application Framework】
OBEX 4. OBEX Application Framework

文章图片


    推荐阅读