Async thin client

[garious]

Add thin_client1.rs. It should implement an entirely asynchronous API and should do timeouts and retries under the hood. Like the current thin client, it can continue to be based on UDP.

It should probably be built on https://tokio.rs/, but if that's too heavyweight, then it could be built from the ground up, using futures and/or mio.

[CriesofCarrots]

@garious et al, got a first mock-up put together. Could you take a look a see if I'm heading in the right direction? https://github.com/CriesofCarrots/solana/blob/thin_client_update/src/thin_client1.rs
I tried tokio first, but I thought mio was more straightfoward.

Questions:
What is the expected scope of this module in the future?

Right now, I have kept the same general thin client structure, set up to specifically handle sending Requests and Events. Do we want this to be more general? (in terms of port selection and data types handled)
I think the get_ and transfer_ functions could also be generalized, if we are likely to be adding attributes to the ThinClient in the future. Do you think that is worthwhile?

Lastly, are there any helper functions you can point me to for writing unit tests for something like this?

[garious]

Not quite what we need. get_last_id() is closest, since it returns a Future, but it's still a synchronous implementation. A thread should listen on a channel for Request messages. When it receives one, it should send it to the server and poll for a response. When it gets the response, it should populate a Future. If it times out, it should retry.

transfer_signed can be generalized to something that sends an arbitrary Event instead of a Transaction. The get_ functions can be generalized to something that sends a Response and returns a Future<Response>, but you'd want another layer of utility functions like get_last_id() make that nice and easy on the users. The user shouldn't need to know about the Request or Response data types.

[CriesofCarrots]

Oh! So in the current implementation, the thread would start up on the instantiation of the thin client and listen through its lifetime?

[garious]

Yep yep!

[CriesofCarrots]

I am about to make the PR, but here are my questions:
I did a lot of experimentation with futures implementation, and ultimately decided to move forward without them. Futures still looks like the ultimate direction to move to me, but the library is so volatile right now (and the examples so out of date), that it seemed to make some sense to get the basic functional blocks in place, and then update to better handling when they release Futures 1.0.

However, I think I am still missing something about the planned runtime implementation. Whether we use futures or not, at some point we still have to wait for the data in order to use it, don't we? I based my code (and these assumptions) off of how the thin client methods are currently used in demo code, but I am wondering if you are envisioning something different down the road...?

One possible approach that would prevent the get_/transfer_ operations from blocking the main thread at all is to decouple the population of the ThinClient data fields from the actual return of the data from the structure. That way, the socket request/response/processing would all happen on another thread and get stored in the ThinClient (I assume this would have to use Arc structure(s)), and the main thread could trundle along doing its thing and utilize client.transaction_count (etc) whenever.
But I'm not clear as to whether this would be viable. I assume that last_id, transaction_count, and balances are only useful when up-to-date. Is this correct?

Thank you!

[garious]

at some point we still have to wait for the data in order to use it, don't we?

Yes, but what makes asynchronous programming different than synchronous programming is that the waiting doesn't necessarily occur directly after sending the request. Instead, you'd send out a batch of requests and then process each response as it arrives. A future is an abstraction that helps us organize this class of programs. In the simplest case, to implement a synchronous API like the one in the thin client, you'd immediately call wait() on each future. To work with an asynchronous API, on the other hand, you'd collect a batch of futures, poll them, and move forward on whatever future is ready first.

[garious]

tokio 0.1.6 looks good. Some nice UDP examples here https://github.com/tokio-rs/tokio/tree/master/examples

[garious]

This is dated