1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
op {
graph_op_name: "Rpc"
in_arg {
name: "address"
description: <<END
`0-D` or `1-D`. The address (i.e. host_name:port) of the RPC server.
If this tensor has more than 1 element, then multiple parallel rpc requests
are sent. This argument broadcasts with `method` and `request`.
END
}
in_arg {
name: "method"
description: <<END
`0-D` or `1-D`. The method address on the RPC server.
If this tensor has more than 1 element, then multiple parallel rpc requests
are sent. This argument broadcasts with `address` and `request`.
END
}
in_arg {
name: "request"
description: <<END
`0-D` or `1-D`. Serialized proto strings: the rpc request argument.
If this tensor has more than 1 element, then multiple parallel rpc requests
are sent. This argument broadcasts with `address` and `method`.
END
}
out_arg {
name: "response"
description: <<END
Same shape as `request`. Serialized proto strings: the rpc responses.
END
}
attr {
name: "protocol"
description: <<END
RPC protocol to use. Empty string means use the default protocol.
Options include 'grpc'.
END
}
attr {
name: "fail_fast"
description: <<END
`boolean`. If `true` (default), then failures to connect
(i.e., the server does not immediately respond) cause an RPC failure.
END
}
attr {
name: "timeout_in_ms"
description: <<END
`int`. If `0` (default), then the kernel will run the RPC
request and only time out if the RPC deadline passes or the session times out.
If this value is greater than `0`, then the op will raise an exception if
the RPC takes longer than `timeout_in_ms`.
END
}
summary: <<END
Perform batches of RPC requests.
END
description: <<END
This op asynchronously performs either a single RPC request, or a batch
of requests. RPC requests are defined by three main parameters:
- `address` (the host+port or BNS address of the request)
- `method` (the RPC method name for the request)
- `request` (the serialized proto string, or vector of strings,
of the RPC request argument).
For example, if you have an RPC service running on port localhost:2345,
and its interface is configured with the following proto declaration:
```
service MyService {
rpc MyMethod(MyRequestProto) returns (MyResponseProto) {
}
};
```
then call this op with arguments:
```
address = "localhost:2345"
method = "MyService/MyMethod"
```
The `request` tensor is a string tensor representing serialized `MyRequestProto`
strings; and the output string tensor `response` will have the same shape
and contain (upon successful completion) corresponding serialized
`MyResponseProto` strings.
For example, to send a single, empty, `MyRequestProto`, call
this op with `request = ""`. To send 5 **parallel** empty requests,
call this op with `request = ["", "", "", "", ""]`.
More generally, one can create a batch of `MyRequestProto` serialized protos
from regular batched tensors using the `encode_proto` op, and convert
the response `MyResponseProto` serialized protos to batched tensors
using the `decode_proto` op.
**NOTE** Working with serialized proto strings is faster than instantiating
actual proto objects in memory, so no performance degradation is expected
compared to writing custom kernels for this workflow.
If the connection fails or the remote worker returns an error
status, the op reraises this exception locally.
See the `TryRpc` op if you prefer to handle RPC failures manually in the graph.
END
}
|
