Asyncio json rpc manager

[shepik]

Requirements

• Make it possible to create raw tcp async server with json-rpc

Description of the Change

• AsyncJSONRPCResponseManager, which is async-version of JSONRPCResponseManager

Alternate Designs

• ?

Benefits

• It allows for request batching - you pause after first request to see if any other requests will arrive, and then process them all in one batch. It's useful to server ML models - see batching at https://github.com/tensorflow/serving/blob/master/tensorflow_serving/g3doc/serving_advanced.md

Possible Drawbacks

• AsyncJSONRPCResponseManager is a lot of copy-paste
• I have not tested JSONRPC20BatchRequest, whether its subrequests are process synchrounously or not.
• I thought using async-version would be slower, but my measurement showed that's insignificant, in terms of throughput at least (i did not measure latency)

Applicable Issues

• 30 - https://github.com/pavlov99/json-rpc/issues/30

[shepik]

I'm not a real python developer, so if the code is not good enough, please point me how i can improve it.

(CI checks failed on python <3.5, which is expected because asyncio)

[liminspace]

I like async python but I think it's not a good idea to mix sync and async library in single package. It can be better to create separate package with the async implementation.

[KostyaEsmukov]

@liminspace could you please further elaborate on your concerns?

For me it's absolutely fine as long as the sync and async code is explicitly separated (by different modules, as in this PR or like in pyzmq), esp. given that the protocol code is common between the two.

[liminspace]

@KostyaEsmukov, if sync and async code have a lot of common code they can be placed together in one library, but must be separated in different modules/files. So your proposition is ok but code must be covered by tests.

[KostyaEsmukov]

@liminspace having tests is certainly required, I totally agree on that. However, the bigger issue with this patch is a lot of copy-paste, which should be abstracted away.

@shepik if you're still interested in working on this, my suggestions would be:

• introduce a common base class, which should contain the common logic between the managers
• either don't import the new async module anywhere (to make sure that python 2 and <3.5 don't break), or make the code python 2 & <3.5 compatible. @asyncio.coroutine and yield from can be used instead of async/await syntax.

[shepik]

Sorry for additional commits, they were not supposed to get here.

Thank you for the response. I do agree with what Kostya said, but i can't do the work required, so it seems i should just close this PR.