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
61 The version is used to ensure protocol compatibility and maxdata
63 is willing to accept.
66 hard-coded maxdata=4096, so CONNECT and AUTH packets sent to a device must not
80 or identifier string.  The banner is used to transmit useful properties.
87 and will need to perform a TLS handshake. version is the current version of
95 The AUTH message informs the recipient that authentication is required to
96 connect to the sender. If type is TOKEN(1), data is a random token that
107 possible, an on-screen confirmation may be displayed for the user to
108 confirm they want to install the public key on the device.
116 identified by local-id that it wishes to connect to the named
126 * "tcp:<host>:<port>" - host may be omitted to indicate localhost
127 * "udp:<host>:<port>" - host may be omitted to indicate localhost
142 connected to the recipient's stream identified by remote-id.
146 A READY message containing a remote-id which does not map to an open
151 is used to establish the connection).  Nonetheless, the local-id MUST
152 not change on later READY messages sent to the same stream.
159 The WRITE message sends data to the recipient's stream identified by
162 A WRITE message containing a remote-id which does not map to an open
182 A CLOSE message containing a remote-id which does not map to an open
186 The recipient should not respond to a CLOSE message in any way.  The
197 The SYNC message was used by the io pump to make sure that stale
198 outbound messages are discarded when the connection to the remote side
199 is broken.  It was only used internally to the bridge and never valid
200 to send across the wire.
202 * when the connection to the remote side goes offline, the io pump
204 * when the connection to the remote side is established, the io pump
205   sends a SYNC(1, token) and continues to discard messages
207   starts accepting messages to forward to the remote side
226 will be a select/epoll loop to handle io between various inbound and
227 outbound connections and the connection to the remote side.
230 reading, one for writing) and a datagram socketpair to provide the
233 kernel interface on linux and osx does not allow you to do meaningful
240 The bridge program will be able to have a number of mini-servers
242 "shell", "fs-bridge", etc) and upon receiving an OPEN() to such a
244 a thread or subprocess to handle the io.
249 For limited environments, like the bootloader, it is allowable to
251 ID numbers such that only one stream may be connected to a bootloader
256 which may be opened to get debug messages from the bootloader and a 
269 the client device could ask the host computer to setup inbound socket
273 The initial design does handshaking to provide flow control, with a
278 The far side may choose to issue the READY message as soon as it receives
279 a WRITE or it may defer the READY until the write to the local stream
280 succeeds.  A future version may want to do some level of windowing where
288 side to request access to a service in the host adb daemon or in the
292 connected the client is talking to that (remote or local) service.