没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Internet Engineering Task Force (IETF) T. Richardson
Request for Comments: 6143 J. Levine
Category: Informational RealVNC Ltd.
ISSN: 2070-1721 March 2011
The Remote Framebuffer Protocol
Abstract
RFB ("remote framebuffer") is a simple protocol for remote access to
graphical user interfaces that allows a client to view and control a
window system on another computer. Because it works at the
framebuffer level, RFB is applicable to all windowing systems and
applications. This document describes the protocol used to
communicate between an RFB client and RFB server. RFB is the
protocol used in VNC.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see
Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6143.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to
BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents
(
http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Richardson & Levine Informational [Page 1]
RFC 6143
The Remote Framebuffer Protocol March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Initial Connection . . . . . . . . . . . . . . . . . . . . . . 4
3. Display Protocol . . . . . . . . . . . . . . . . . . . . . . . 4
4. Input Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Representation of Pixel Data . . . . . . . . . . . . . . . . . 5
6. Protocol Versions and Extensions . . . . . . . . . . . . . . . 6
7. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Handshake Messages . . . . . . . . . . . . . . . . . . . . 8
7.1.1. ProtocolVersion Handshake . . . . . . . . . . . . . . 8
7.1.2. Security Handshake . . . . . . . . . . . . . . . . . . 8
7.1.3. SecurityResult Handshake . . . . . . . . . . . . . . . 10
7.2. Security Types . . . . . . . . . . . . . . . . . . . . . . 10
7.2.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2.2. VNC Authentication . . . . . . . . . . . . . . . . . . 10
7.3. Initialization Messages . . . . . . . . . . . . . . . . . 11
7.3.1. ClientInit . . . . . . . . . . . . . . . . . . . . . . 11
7.3.2. ServerInit . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Pixel Format Data Structure . . . . . . . . . . . . . . . 12
7.5. Client-to-Server Messages . . . . . . . . . . . . . . . . 13
7.5.1. SetPixelFormat . . . . . . . . . . . . . . . . . . . . 13
7.5.2. SetEncodings . . . . . . . . . . . . . . . . . . . . . 14
7.5.3. FramebufferUpdateRequest . . . . . . . . . . . . . . . 15
7.5.4. KeyEvent . . . . . . . . . . . . . . . . . . . . . . . 16
7.5.5. PointerEvent . . . . . . . . . . . . . . . . . . . . . 19
7.5.6. ClientCutText . . . . . . . . . . . . . . . . . . . . 19
7.6. Server-to-Client Messages . . . . . . . . . . . . . . . . 20
7.6.1. FramebufferUpdate . . . . . . . . . . . . . . . . . . 20
7.6.2. SetColorMapEntries . . . . . . . . . . . . . . . . . . 21
7.6.3. Bell . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6.4. ServerCutText . . . . . . . . . . . . . . . . . . . . 22
7.7. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 22
7.7.1. Raw Encoding . . . . . . . . . . . . . . . . . . . . . 23
7.7.2. CopyRect Encoding . . . . . . . . . . . . . . . . . . 23
7.7.3. RRE Encoding . . . . . . . . . . . . . . . . . . . . . 23
7.7.4. Hextile Encoding . . . . . . . . . . . . . . . . . . . 24
7.7.5. TRLE . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.7.6. ZRLE . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.8. Pseudo-Encodings . . . . . . . . . . . . . . . . . . . . . 30
7.8.1. Cursor Pseudo-Encoding . . . . . . . . . . . . . . . . 30
7.8.2. DesktopSize Pseudo-Encoding . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. RFB Security Types . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Registry Name . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 32
8.2. Client-to-Server Message Types . . . . . . . . . . . . . . 32
8.2.1. Registry Name . . . . . . . . . . . . . . . . . . . . 32
Richardson & Levine Informational [Page 2]
RFC 6143
The Remote Framebuffer Protocol March 2011
8.2.2. Registry Contents . . . . . . . . . . . . . . . . . . 32
8.3. Server-to-Client Message Types . . . . . . . . . . . . . . 33
8.3.1. Registry Name . . . . . . . . . . . . . . . . . . . . 33
8.3.2. Registry Contents . . . . . . . . . . . . . . . . . . 33
8.4. RFB Encoding Types . . . . . . . . . . . . . . . . . . . . 34
8.4.1. Registry Name . . . . . . . . . . . . . . . . . . . . 34
8.4.2. Registry Contents . . . . . . . . . . . . . . . . . . 34
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Differences in Earlier Protocol Versions . . . . . . 38
A.1. Differences in the Version 3.3 Protocol . . . . . . . . . 38
A.2. Differences in the Version 3.7 Protocol . . . . . . . . . 38
1
. Introduction
RFB ("remote framebuffer") is a simple protocol for remote access to
graphical user interfaces. Because it works at the framebuffer
level, it is applicable to all windowing systems and applications,
including X11, Windows, and Macintosh. RFB is the protocol used in
VNC. The protocol is widely implemented and has had fairly good
interoperability.
The remote endpoint where the user sits (typically with a display,
keyboard, and pointer) is called the RFB client or viewer. The
endpoint where changes to the framebuffer originate (i.e., the
windowing system and applications) is known as the RFB server.
RFB is a "thin client" protocol. The emphasis in the design of the
RFB protocol is to make very few requirements of the client. In this
way, clients can run on the widest range of hardware, and the task of
implementing a client is made as simple as possible.
The protocol also makes the client stateless. If a client
disconnects from a given server and subsequently reconnects to that
same server, the state of the user interface is preserved.
Furthermore, a different client endpoint can be used to connect to
the same RFB server. At the new endpoint, the user will see exactly
the same graphical user interface as at the original endpoint. In
effect, the interface to the user’s applications becomes completely
mobile. Wherever suitable network connectivity exists, the user can
access their own personal applications, and the state of these
applications is preserved between accesses from different locations.
This provides the user with a familiar, uniform view of the computing
infrastructure wherever they go.
Richardson & Levine Informational [Page 3]
RFC 6143
The Remote Framebuffer Protocol March 2011
The RFB protocol has evolved over the past decade, and has been
implemented several times, including at least one open source
version. This document describes the RFB protocol as actually
implemented, so that future implementers can interoperate with
existing clients and servers.
2. Initial Connection
An RFB server is typically a long-lived process that maintains the
state of a framebuffer. RFB clients typically connect, communicate
with the server for a period of time to use and manipulate the
framebuffer, then disconnect. A subsequent RFB session will then
pick up where a prior session left off, with the state of the
framebuffer intact.
An RFB client contacts the server on TCP port 5900. On systems with
multiple RFB servers, server N typically listens on port 5900+N,
analogous to the way that X Window servers listen on port 6000+N.
Some browser-based clients use a Java application to run the RFB
protocol. RFB servers sometimes provide a simple HTTP server on port
5800 that provides the requisite Java applet.
In some cases, the initial roles of the client and server are
reversed, with the RFB client listening on port 5500, and the RFB
server contacting the RFB client. Once the connection is
established, the two sides take their normal roles, with the RFB
server sending the first handshake message.
Note that the only port number assigned by IANA for RFB is port 5900,
so RFB clients and servers should avoid using other port numbers
unless they are communicating with servers or clients known to use
the non-standard ports.
3. Display Protocol
The display side of the protocol is based around a single graphics
primitive: "put a rectangle of pixel data at a given x,y position".
This might seem an inefficient way of drawing many user interface
components. However, allowing various different encodings for the
pixel data gives us a large degree of flexibility in how to trade off
various parameters such as network bandwidth, client drawing speed,
and server processing speed.
Richardson & Levine Informational [Page 4]
RFC 6143
The Remote Framebuffer Protocol March 2011
A sequence of these rectangles makes a framebuffer update (simply
referred to here as "update"). An update represents a change from
one valid framebuffer state to another, so in some ways is similar to
a frame of video. The rectangles in an update are usually but not
always disjoint.
The update protocol is demand-driven by the client. That is, an
update is only sent from the server to the client in response to an
explicit request from the client. This gives the protocol an
adaptive quality. The slower the client and the network are, the
lower the rate of updates. With typical applications, changes to the
same area of the framebuffer tend to happen soon after one another.
With a slow client or network, transient states of the framebuffer
can be ignored, resulting in less network traffic and less drawing
for the client.
After the initial handshake sequence, the protocol is asynchronous,
with each side sending messages as needed. The server must not send
unsolicited updates. An update must only be sent in response to a
request from the client. When several requests from the client are
outstanding, a single update from the server may satisfy all of them.
4. Input Protocol
The input side of the protocol is based on a standard workstation
model of a keyboard and multi-button pointing device. Input events
are simply sent to the server by the client whenever the user presses
a key or pointer button, or whenever the pointing device is moved.
These input events can also be synthesized from other non-standard
I/O devices. For example, a pen-based handwriting recognition engine
might generate keyboard events.
5. Representation of Pixel Data
Initial interaction between the RFB client and server involves a
negotiation of the format and encoding of the pixel data that will be
sent. This negotiation has been designed to make the job of the
client as easy as possible. The server must always be able to supply
pixel data in the form the client wants. However, if the client is
able to cope equally with several different formats or encodings, it
may choose one that is easier for the server to produce.
Pixel format refers to the representation of individual colors by
pixel values. The most common pixel formats are 24-bit or 16-bit
"true color", where bit-fields within the pixel value translate
directly to red, green, and blue intensities, and 8-bit "color map"
(palette) where the pixel values are indices into a 256-entry table
that contains the actual RGB intensities.
Richardson & Levine Informational [Page 5]
剩余38页未读,继续阅读
资源评论
- 滕扬Lance2023-07-27文件中的内容结构清晰,通俗易懂,使读者能够快速掌握RFB协议的关键概念。
- Crazyanti2023-07-27这份文件详细介绍了RFB协议(VNC协议)的重要性和应用,非常了解需求。
- KerstinTongxi2023-07-27这份文件还提供了一些实际案例和推荐资源,帮助读者进一步了解RFB协议在实际应用中的效果和拓展。
- 以墨健康道2023-07-27在介绍RFB协议的实现原理时,文件给出了许多实用的示例,让读者能够更好地理解其工作原理。
- 坑货两只2023-07-27阐述了RFB协议的优点和局限性,对读者来说具有参考价值,帮助读者更好地评估其适用性。
house01house
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功