aboutsummaryrefslogtreecommitdiffstats
path: root/android/async-socket-connector.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix Windows buildVladimir Chtchetkine2012-04-301-0/+4
| | | | Change-Id: I732fa0d756656ad9976eddd06b16644e208aa512
* Use new SdkController communication protocol for emulation portsVladimir Chtchetkine2012-04-301-2/+0
| | | | | | | | | | | | | | 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
* Implements SDKCtlSocket that implements communication protocol wih SdkControllerVladimir Chtchetkine2012-04-061-25/+68
| | | | | | | In addition, this CL contains some minor tweaks to async-socket, and async-socket-connector that improve tracebility. Change-Id: Ib1309b19dcd02e96379155fea7015019d93160e7
* Make all async I/O object referenced.Vladimir Chtchetkine2012-04-031-36/+76
| | | | | | | | | 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
* Refactor asynchronous socket APIsVladimir Chtchetkine2012-04-021-58/+63
| | | | | | | | | | | | | | | 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
* Implements an asynchronous socket connector with retriesVladimir Chtchetkine2012-03-271-0/+322
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