没有合适的资源?快使用搜索试试~ 我知道了~
首页D-Bus Specification
资源详情
资源评论
资源推荐
D-Bus Specification
Havoc Pennington
Red Hat, Inc.
<
hp@pobox.com>
Anders Carlsson
CodeFactory AB
<
andersca@codefactory.se>
Alexander Larsson
Red Hat, Inc.
<
alexl@redhat.com>
Version 0.12
Table of Contents
Introduction
Protocol and Specification Stability
Message Protocol
Type Signatures
Marshaling (Wire Format)
Message Format
Valid Names
Message Types
Invalid Protocol and Spec Extensions
Authentication Protocol
Protocol Overview
Special credentials-passing nul byte
AUTH command
CANCEL Command
DATA Command
BEGIN Command
REJECTED Command
OK Command
ERROR Command
Authentication examples
Authentication state diagrams
Authentication mechanisms
Server Addresses
Transports
Unix Domain Sockets
Naming Conventions
UUIDs
Standard Interfaces
org.freedesktop.DBus.Peer
org.freedesktop.DBus.Introspectable
org.freedesktop.DBus.Properties
Introspection Data Format
Message Bus Specification
Message Bus Overview
Message Bus Names
Message Bus Message Routing
Message Bus Starting Services
Well-known Message Bus Instances
Message Bus Messages
Glossary
Introduction
D-Bus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC). In more detail:
• D-Bus is low-latency because it is designed to avoid round trips
and allow asynchronous operation, much like the X protocol.
• D-Bus is low-overhead because it uses a binary protocol, and does
not have to convert to and from a text format such as XML. Because
D-Bus is intended for potentially high-resolution same-machine
IPC, not primarily for Internet IPC, this is an interesting
optimization.
• D-Bus is easy to use because it works in terms of messages rather
than byte streams, and automatically handles a lot of the hard
IPC issues. Also, the D-Bus library is designed to be wrapped
in a way that lets developers use their framework's existing
object/type system, rather than learning a new one specifically
for IPC.
The base D-Bus protocol is a one-to-one (peer-to-peer or client-server)
protocol, specified in
the section called “Message Protocol”. That
is, it is a system for one application to talk to a single other
application. However, the primary intended application of the protocol
is the D-Bus message bus, specified in
the section called “Message
Bus Specification”. The message bus is a special application that
accepts connections from multiple other applications, and forwards
messages among them.
Uses of D-Bus include notification of system changes (notification
of when a camera is plugged in to a computer, or a new version of some
software has been installed), or desktop interoperability, for example
a file monitoring service or a configuration service.
D-Bus is designed for two specific use cases:
• A "system bus" for notifications from the system to user sessions,
and to allow the system to request input from user sessions.
• A "session bus" used to implement desktop environments such as
GNOME and KDE.
D-Bus is not intended to be a generic IPC system for any possible
application, and intentionally omits many features found in other IPC
systems for this reason.
At the same time, the bus daemons offer a number of features not found
in other IPC systems, such as single-owner "bus names" (similar to
X selections), on-demand startup of services, and security policies.
In many ways, these features are the primary motivation for developing
D-Bus; other systems would have sufficed if IPC were the only goal.
D-Bus may turn out to be useful in unanticipated applications, but
future versions of this spec and the reference implementation probably
will not incorporate features that interfere with the core use cases.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. However, the
document could use a serious audit to be sure it makes sense to do
so. Also, they are not capitalized.
Protocol and Specification Stability
The D-Bus protocol is frozen (only compatible extensions are allowed)
as of November 8, 2006. However, this specification could still use
a fair bit of work to make interoperable reimplementation possible
without reference to the D-Bus reference implementation. Thus, this
specification is not marked 1.0. To mark it 1.0, we'd like to see someone
invest significant effort in clarifying the specification language,
and growing the specification to cover more aspects of the reference
implementation's behavior.
Until this work is complete, any attempt to reimplement D-Bus will
probably require looking at the reference implementation and/or asking
questions on the D-Bus mailing list about intended behavior. Questions
on the list are very welcome.
Nonetheless, this document should be a useful starting point and is
to our knowledge accurate, though incomplete.
Message Protocol
A message consists of a header and a body. If you think of a message
as a package, the header is the address, and the body contains the
package contents. The message delivery system uses the header
information to figure out where to send the message and how to interpret
it; the recipient interprets the body of the message.
The body of the message is made up of zero or more arguments, which
are typed values, such as an integer or a byte array.
Both header and body use the same type system and format for serializing
data. Each type of value has a wire format. Converting a value from
some other representation into the wire format is called marshaling
and converting it back from the wire format is unmarshaling.
Type Signatures
The D-Bus protocol does not include type tags in the marshaled data;
a block of marshaled values must have a known type signature. The type
signature is made up of type codes. A type code is an ASCII character
representing the type of a value. Because ASCII characters are used,
the type signature will always form a valid ASCII string. A simple
string compare determines whether two type signatures are equivalent.
As a simple example, the type code for 32-bit integer (INT32) is the
ASCII character 'i'. So the signature for a block of values containing
a single INT32 would be:
"i"
A block of values containing two INT32 would have this signature:
"ii"
All basic types work like INT32 in this example. To marshal and
unmarshal basic types, you simply read one value from the data block
corresponding to each type code in the signature. In addition to basic
types, there are four container types: STRUCT, ARRAY, VARIANT, and
DICT_ENTRY.
STRUCT has a type code, ASCII character 'r', but this type code does
not appear in signatures. Instead, ASCII characters '(' and ')' are
used to mark the beginning and end of the struct. So for example, a
struct containing two integers would have this signature:
"(ii)"
Structs can be nested, so for example a struct containing an integer
and another struct:
"(i(ii))"
剩余59页未读,继续阅读
mapped
- 粉丝: 0
- 资源: 4
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- RTL8188FU-Linux-v5.7.4.2-36687.20200602.tar(20765).gz
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
- SPC统计方法基础知识.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论1