Lines Matching refs:to
4 When it comes down to it, aproto's primary purpose is to forward
9 to an extremely straightforward model optimized to accomplish the
14 be used by either commandline or interactive tools to communicate with
15 a device or emulator that is connected to the bridge.
17 The protocol is designed to be straightforward and well-defined enough
18 that if it needs to be reimplemented in another environment (Java
22 implementation to be much more robust.
50 The identifiers "local-id" and "remote-id" are always relative to the
59 The version is used to ensure protocol compatibility and maxdata
61 is willing to accept.
75 or identifier string. The banner is used to transmit useful properties.
80 The AUTH message informs the recipient that authentication is required to
81 connect to the sender. If type is TOKEN(1), data is a random token that
92 possible, an on-screen confirmation may be displayed for the user to
93 confirm they want to install the public key on the device.
99 identified by local-id that it wishes to connect to the named
109 * "tcp:<host>:<port>" - host may be omitted to indicate localhost
110 * "udp:<host>:<port>" - host may be omitted to indicate localhost
122 connected to the recipient's stream identified by remote-id.
126 A READY message containing a remote-id which does not map to an open
131 is used to establish the connection). Nonetheless, the local-id MUST
132 not change on later READY messages sent to the same stream.
138 The WRITE message sends data to the recipient's stream identified by
141 A WRITE message containing a remote-id which does not map to an open
159 A CLOSE message containing a remote-id which does not map to an open
163 The recipient should not respond to a CLOSE message in any way. The
170 The SYNC message is used by the io pump to make sure that stale
171 outbound messages are discarded when the connection to the remote side
172 is broken. It is only used internally to the bridge and never valid
173 to send across the wire.
175 * when the connection to the remote side goes offline, the io pump
177 * when the connection to the remote side is established, the io pump
178 sends a SYNC(1, token) and continues to discard messages
180 starts accepting messages to forward to the remote side
198 will be a select/epoll loop to handle io between various inbound and
199 outbound connections and the connection to the remote side.
202 reading, one for writing) and a datagram socketpair to provide the
205 kernel interface on linux and osx does not allow you to do meaningful
212 The bridge program will be able to have a number of mini-servers
214 "shell", "fs-bridge", etc) and upon receiving an OPEN() to such a
216 a thread or subprocess to handle the io.
221 For limited environments, like the bootloader, it is allowable to
223 ID numbers such that only one stream may be connected to a bootloader
228 which may be opened to get debug messages from the bootloader and a
241 the client device could ask the host computer to setup inbound socket
245 The initial design does handshaking to provide flow control, with a
250 The far side may choose to issue the READY message as soon as it receives
251 a WRITE or it may defer the READY until the write to the local stream
252 succeeds. A future version may want to do some level of windowing where
260 side to request access to a service in the host adb daemon or in the
264 connected the client is talking to that (remote or local) service.