--- a replacement for aproto -------------------------------------------
When it comes down to it, aproto's primary purpose is to forward
various streams between the host computer and client device (in either
direction).
This replacement further simplifies the concept, reducing the protocol
to an extremely straightforward model optimized to accomplish the
forwarding of these streams and removing additional state or
complexity.
The host side becomes a simple comms bridge with no "UI", which will
be used by either commandline or interactive tools to communicate with
a device or emulator that is connected to the bridge.
The protocol is designed to be straightforward and well-defined enough
that if it needs to be reimplemented in another environment (Java
perhaps), there should not problems ensuring perfect interoperability.
The protocol discards the layering aproto has and should allow the
implementation to be much more robust.
--- protocol overview and basics ---------------------------------------
The transport layer deals in "messages", which consist of a 24 byte
header followed (optionally) by a payload. The header consists of 6
32 bit words which are sent across the wire in little endian format.
struct message {
unsigned command; /* command identifier constant */
unsigned arg0; /* first argument */
unsigned arg1; /* second argument */
unsigned data_length; /* length of payload (0 is allowed) */
unsigned data_crc32; /* crc32 of data payload */
unsigned magic; /* command ^ 0xffffffff */
};
Receipt of an invalid message header, corrupt message payload, or an
unrecognized command MUST result in the closing of the remote
connection. The protocol depends on shared state and any break in the
message stream will result in state getting out of sync.
The following sections describe the six defined message types in
detail. Their format is COMMAND(arg0, arg1, payload) where the payload
is represented by a quoted string or an empty string if none should be
sent.
The identifiers "local-id" and "remote-id" are always relative to the
*sender* of the message, so for a receiver, the meanings are effectively
reversed.
--- CONNECT(version, maxdata, "system-identity-string") ----------------
The CONNECT message establishes the presence of a remote system.
The version is used to ensure protocol compatibility and maxdata
declares the maximum message body size that the remote system
is willing to accept.
Currently, version=0x01000000 and maxdata=4096
Both sides send a CONNECT message when the connection between them is
established. Until a CONNECT message is received no other messages may
be sent. Any messages received before a CONNECT message MUST be ignored.
If a CONNECT message is received with an unknown version or insufficiently
large maxdata value, the connection with the other side must be closed.
The system identity string should be "<systemtype>:<serialno>:<banner>"
where systemtype is "bootloader", "device", or "host", serialno is some
kind of unique ID (or empty), and banner is a human-readable version
or identifier string (informational only).
--- OPEN(local-id, 0, "destination") -----------------------------------
The OPEN message informs the recipient that the sender has a stream
identified by local-id that it wishes to connect to the named
destination in the message payload. The local-id may not be zero.
The OPEN message MUST result in either a READY message indicating that
the connection has been established (and identifying the other end) or
a CLOSE message, indicating failure. An OPEN message also implies
a READY message sent at the same time.
Common destination naming conventions include:
* "tcp:<host>:<port>" - host may be omitted to indicate localhost
* "udp:<host>:<port>" - host may be omitted to indicate localhost
* "local-dgram:<identifier>"
* "local-stream:<identifier>"
* "shell" - local shell service
* "upload" - service for pushing files across (like aproto's /sync)
* "fs-bridge" - FUSE protocol filesystem bridge
--- READY(local-id, remote-id, "") -------------------------------------
The READY message informs the recipient that the sender's stream
identified by local-id is ready for write messages and that it is
connected to the recipient's stream identified by remote-id.
Neither the local-id nor the remote-id may be zero.
A READY message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have been
closed while this message was in-flight.
The local-id is ignored on all but the first READY message (where it
is used to establish the connection). Nonetheless, the local-id MUST
not change on later READY messages sent to the same stream.
--- WRITE(0, remote-id, "data") ----------------------------------------
The WRITE message sends data to the recipient's stream identified by
remote-id. The payload MUST be <= maxdata in length.
A WRITE message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have been
closed while this message was in-flight.
A WRITE message may not be sent until a READY message is received.
Once a WRITE message is sent, an additional WRITE message may not be
sent until another READY message has been received. Recipients of
a WRITE message that is in violation of this requirement will CLOSE
the connection.
--- CLOSE(local-id, remote-id, "") -------------------------------------
The CLOSE message informs recipient that the connection between the
sender's stream (local-id) and the recipient's stream (remote-id) is
broken. The remote-id MUST not be zero, but the local-id MAY be zero
if this CLOSE indicates a failed OPEN.
A CLOSE message containing a remote-id which does not map to an open
stream on the recipient's side is ignored. The stream may have
already been closed by the recipient while this message was in-flight.
The recipient should not respond to a CLOSE message in any way. The
recipient should cancel pending WRITEs or CLOSEs, but this is not a
requirement, since they will be ignored.
--- SYNC(online, sequence, "") -----------------------------------------
The SYNC message is used by the io pump to make sure that stale
outbound messages are discarded when the connection to the remote side
is broken. It is only used internally to the bridge and never valid
to send across the wire.
* when the connection to the remote side goes offline, the io pump
sends a SYNC(0, 0) and starts discarding all messages
* when the connection to the remote side is established, the io pump
sends a SYNC(1, token) and continues to discard messages
* when the io pump receives a matching SYNC(1, token), it once again
starts accepting messages to forward to the remote side
--- message command constants ------------------------------------------
#define A_SYNC 0x434e5953
#define A_CNXN 0x4e584e43
#define A_OPEN 0x4e45504f
#define A_OKAY 0x59414b4f
#define A_CLSE 0x45534c43
#define A_WRTE 0x45545257
--- implementation details ---------------------------------------------
The core of the bridge program will use three threads. One thread
will be a select/epoll loop to handle io between various inbound and
outbound connections and the connection to the remote side.
The remote side connection will be implemented as two threads (one for
reading, one for writing) and a datagram socketpair to provide the
channel between the main select/epoll thread and the remote connection
threadpair. The reason for this is that for usb connections, the
kernel interface on linux and osx does not allow you to do meaningful
nonblocking IO.
The endian swapping for the message headers will happen (as needed) in
the remote connection threadpair and that the rest of the program will
always treat message header values as native-endian.
The bridge program
没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
收起资源包目录
编译Adb源码(VS2012) (179个子文件)
commandline.cpp 62KB
sysdeps_win32.cpp 60KB
adb.cpp 49KB
transport.cpp 31KB
file_sync_client.cpp 26KB
sockets.cpp 25KB
services.cpp 19KB
usb_windows.cpp 14KB
transport_local.cpp 14KB
usb_vendors.cpp 11KB
adb_auth_host.cpp 9KB
adb_client.cpp 8KB
centraldir.cpp 6KB
zipfile.cpp 3KB
transport_usb.cpp 3KB
list.cpp 1024B
console.cpp 1009B
get_my_path_windows.cpp 962B
sockets.dia 2KB
adb.exe 576KB
adb.vcxproj.filters 4KB
safestack.h 134KB
obj_mac.h 129KB
zlib.h 86KB
zlib.h 86KB
ssl.h 84KB
asn1.h 48KB
x509.h 47KB
evp.h 38KB
engine.h 38KB
bn.h 33KB
objects.h 33KB
bio.h 31KB
x509v3.h 29KB
adb_api.h 29KB
adb_api.h 29KB
pem.h 28KB
asn1t.h 27KB
store.h 26KB
crypto.h 24KB
ocsp.h 24KB
ssl3.h 23KB
ec.h 21KB
symhacks.h 21KB
x509_vfy.h 20KB
rsa.h 19KB
tls1.h 19KB
asn1_mac.h 19KB
des_old.h 18KB
ui.h 16KB
pkcs7.h 16KB
dso.h 16KB
zconf.h 15KB
zconf.h 15KB
pkcs12.h 13KB
err.h 13KB
sysdeps.h 13KB
log.h 13KB
adb.h 12KB
dsa.h 11KB
des.h 10KB
ssl2.h 10KB
ecdsa.h 10KB
e_os2.h 9KB
conf.h 9KB
dh.h 8KB
usb100.h 8KB
atomic-arm.h 8KB
krb5_asn.h 7KB
dtls1.h 7KB
lhash.h 7KB
sha.h 7KB
opensslconf.h 7KB
ossl_typ.h 7KB
rand.h 6KB
pq_compat.h 6KB
kssl.h 6KB
aes.h 6KB
adb_trace.h 5KB
atomic-mips.h 5KB
camellia.h 5KB
blowfish.h 5KB
md5.h 5KB
md4.h 5KB
atomic.h 5KB
ecdh.h 5KB
buffer.h 4KB
cast.h 4KB
idea.h 4KB
hmac.h 4KB
stack.h 4KB
rc2.h 4KB
ripemd.h 4KB
txt_db.h 4KB
tmdiff.h 4KB
atomic-x86.h 4KB
conf_api.h 4KB
threads.h 4KB
md2.h 4KB
selector.h 4KB
共 179 条
- 1
- 2
资源评论
- BattleCoder2019-03-08再来看下能不能编译
- cffy6252018-08-08还不错,可以参考一下
lk1213342234
- 粉丝: 1
- 资源: 4
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功