| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
android/sdk-control-socket.* has replaced android/android-device.* as the back-bone
of communicating with SDK controller on the device. The major differences are:
- New communication protocol uses just one (async) socket connection to communicate
with the device (the old one used two sockets: one sync, and another - async).
- New communication protocol connects to one TCP port (1970 in this CL) for all emulation
ports. Channel multiplexing is done by using port names, and assigning a separate socket
for communication inside each separate port. The old protocol had separate TCP ports for
each emulation ports (1968 for sensors, and 1969 for multi-touch)
Change-Id: I779fcbdfba2f9b4c433a9d76a567975708b00469
|
| |
|
|
|
|
|
| |
In addition, this CL contains some minor tweaks to async-socket, and
async-socket-connector that improve tracebility.
Change-Id: Ib1309b19dcd02e96379155fea7015019d93160e7
|
| |
|
|
|
|
|
|
|
| |
Since it's hard to control lifespan of an object in asynchronous environment, we
should make all AsyncXxx objects a referenced objecst, that will self-destruct
when its reference count drops to zero, indicating that the last client that
used the object has abandoned it.
Change-Id: I6f8194aa14e52a23a8772d827583782989654504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial implementation was a bit too complex in two ways:
1. Each component (the connector, and async socket) had its own set of state and
action enums, which was confusing, required value translation, and was not really
needed. So, all these enums have been combined into two common enums that are now
declared in android/async-io-common.h
2. Too many callbacks, which really complicated implementation of the clients. It is
much more efficient to have just two callbacks (one to monitor connection, and another
to monitor I/O), letting the client to dispatch on particular event (success/timeout/etc.)
This CL fixes these two issues.
Change-Id: I545c93dee2e9e9c72c1d25e6cd218c8680933ee3
|
|
|
The typical usage of the API is as such:
1. The client creates an async connector instance by calling async_socket_connector_new
routine, supplying there address of the socket to connect, and a callback
to invoke on connection events.
2. The client then proceeds with calling async_socket_connector_connect that
would initiate connection attempts.
The main job on the client side falls on the client's callback routine that
serves the connection events. Once connection has been initiated, the connector
will invoke that callback to report current connection status.
In general, there are three connection events passed to the callback:
1. Success.
2. Failure.
3. Retry.
Typically, when client's callback is called for successful connection, the
client will pull connected socket's FD from the connector, and then this FD
will be used by the client for I/O on the connected socket. If socket's FD
is pulled by the client, it must return ASC_CB_KEEP from the callback.
When client's callback is invoked with an error (ASC_CONNECTION_FAILED event),
the client has an opportunity to review the error (available in 'errno'), and
either abort the connection by returning ASC_CB_ABORT, or schedule a retry
by returning ASC_CB_RETRY from the callback. If client returns ASC_CB_ABORT
from the callback, the connector will stop connection attempts, and will
self-destruct. If ASC_CB_RETRY is returned from the callback, the connector
will retry connection attempt after timeout that was set by the caller in the
call to async_socket_connector_new routine.
When client's callback is invoked with ASC_CONNECTION_RETRY, the client has an
opportunity to cancel further connection attempts by returning ASC_CB_ABORT,
or it can allow another connection attempt by returning ASC_CB_RETRY.
The client has no control over the lifespan of initialized connector instance.
It always self-destructs after client's cllback returns with a status other
than ASC_CB_RETRY.
Change-Id: I39b0057013e45ee10d1ef98905b8a5210656a26c
|
