* `c.conn` may be already invalidated but the rpc client can't detect this.
`NewStream` may hang trying to open a stream with invalidated connection.
Using timer with `dialTimeout` for `NewStream` fixes this problem.
Signed-off-by: Airat Arifullin <a.arifullin@yadro.com>
In previous implementation `Client` passed `context.Background()` to
`grpc.DialContext` function. This didn't allow to abort dial stage by
the given context.
Base dial context on the one provided with `WithContext` option. Fall
back to using `context.Background` if context is not specified.
Signed-off-by: Leonard Lyubich <ctulhurider@gmail.com>
In previous implementation `Client` didn't block until the connection is
up on dial stage. This caused the dial timeout to have no effect.
Provide `WithBlock` dial option to `DialContext` call in `openGRPCConn`
method. From now `Client` blocks for configured timeout until the
connection is up.
Signed-off-by: Leonard Lyubich <ctulhurider@gmail.com>
`grpc.WithInsecure` has been marked as deprecated in earlier releases of
`google.golang.org/grpc`.
Use `google.golang.org/grpc/credentials/insecure` package instead as
recommended.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
From the docs of `time.After`:
```
The underlying Timer is not recovered by the garbage collector until the timer fires.
```
We have 1 minute default timeout, which is pretty long given that most
of the time we exchange small messages.
Signed-off-by: Evgenii Stratonikov <evgeniy@nspcc.ru>
Remote gRPC server may not return or accept data for a while. gRPC
solves this issue with timeout in context. However, the context is
used for entire gRPC method invocation. Unfortunately the duration
of requests with streams can't be estimated easily.
To solve this issue we can specify timeouts for every message read
and write. Single message has size limit so timeout can be related
to that.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
Add `WithURIAddress` option to client.
It parses passed address with
`url.ParseRequestURI` function and
use(or not) TLS over grpc connection
based on retrieved scheme('grpc' or
'grpcs').
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Implement `Client.Conn` which returns the connection of the underlying
transport client. The method is going to be used for forwarding the
connection to superior clients.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Implement `Client.Conn` method which returns underlying connection as
`io.Closer`. Method is going to be used for forwarding the connection to
superior clients.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Add `WithTLSConfig` option to client.
If it is not nil then client will
try to open secured connection.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Implement generic `Client` that can communicate with the remote server via
protobuf `Message`'s. The client can uniformly execute any protobuf RPC
on the remote server using any of the supported transport protocols.
Currently only gRPC protocol is supported.
Additionally implement helpful functions to transmit messages by one of the
flow types: unary, client- or server-side stream.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Define `Message` interface of the generic protobuf message. In the initial
implementation, the message should be convertible to and from related gRPC
message.
Implement encoding functions over the `Message` that can:
* unmarshal the `Message` via related gRPC message;
* decode the `Message` from JSON format via related gRPC message;
* encode the `Message` to JSON.
Implement nested `test` package for testing the implementation.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Implement gRPC client that can uniformly execute any RPC on the remote
server. In the primary implementation, the client is a thin wrapper over
gRPC client connection that is required to create the client. In the future,
it is planned to expand the library with convenient functionality.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
