Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
G
Grpc
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
tci-gateway-module
Grpc
Commits
9065c8b1
Commit
9065c8b1
authored
8 years ago
by
David Garcia Quintas
Browse files
Options
Downloads
Patches
Plain Diff
more changes after offline chat with ejona
parent
485cf40a
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/interop-test-descriptions.md
+20
-65
20 additions, 65 deletions
doc/interop-test-descriptions.md
with
20 additions
and
65 deletions
doc/interop-test-descriptions.md
+
20
−
65
View file @
9065c8b1
...
...
@@ -90,11 +90,11 @@ Client asserts:
*
clients are free to assert that the response payload body contents are zero
and comparing the entire response message against a golden response
###
large
_compressed_unary
###
server
_compressed_unary
This test verifies compressed unary calls succeed in sending
messages. It
sends one unary request for every payload type, with and without
requesting a
compressed response from the server.
This test verifies compressed
server-only
unary calls succeed in sending
messages. It
sends one unary request for every payload type, with and without
requesting a
compressed response from the server.
In all scenarios, whether compression was actually performed is determined by
the compression bit in the response's message flags.
...
...
@@ -103,7 +103,6 @@ the compression bit in the response's message flags.
Server features:
*
[
UnaryCall
][]
*
[
Compressable Payload
][]
*
[
Uncompressable Payload
][]
Procedure:
1.
Client calls UnaryCall with:
...
...
@@ -130,26 +129,6 @@ Procedure:
zero and comparing the entire response message against a golden response
2.
Client calls UnaryCall with:
```
{
request_compressed_response: bool
response_type: UNCOMPRESSABLE
response_size: 314159
payload:{
body: 271828 bytes of zeros
}
}
```
Client asserts:
*
call was successful
*
response payload type is UNCOMPRESSABLE
*
the response MAY have the compressed message flag set. Some
implementations will choose to compress the payload even when the output
size if larger than the input.
*
response payload body is 314159 bytes in size
### client_streaming
This test verifies that client-only streaming succeeds.
...
...
@@ -250,7 +229,6 @@ This test verifies that server-only compressed streaming succeeds.
Server features:
*
[
StreamingOutputCall
][]
*
[
Compressable Payload
][]
*
[
Uncompressable Payload
][]
Procedure:
...
...
@@ -258,46 +236,26 @@ Procedure:
```
{
request_compressed_response:
bool
request_compressed_response:
true
response_type:COMPRESSABLE
response_parameters:{
size: 314
24
size: 314
15
}
response_parameters:{
size:
61632
size:
58979
}
}
```
Note that the `response_parameters` sizes are the sum of the usual streaming
response sizes (31415, 9, 2653, 58979) taken in successive pairs. This way,
we only keep a single list of sizes while making sure the individual message
sizes are large enough to trigger compression in all implementations.
Client asserts:
* call was successful
* exactly four responses
* response payloads are COMPRESSABLE
* if `request_compressed_response` is false, the response's messages MUST
NOT have the compressed message flag set.
* if `request_compressed_response` is true, the response's messages MUST
have the compressed message flag set.
* response payload bodies are sized (in order): 31424, 61632
* clients are free to assert that the response payload body contents are
zero and comparing the entire response messages against golden responses
2.
Client calls StreamingOutputCall with:
```
{
request_compressed_response:
bool
response_type:
UN
COMPRESSABLE
request_compressed_response:
false
response_type:COMPRESSABLE
response_parameters:{
size: 314
24
size: 314
15
}
response_parameters:{
size:
61632
size:
58979
}
}
```
...
...
@@ -305,11 +263,15 @@ Procedure:
Client asserts:
* call was successful
* exactly four responses
* response payloads are UNCOMPRESSABLE
* the response MAY have the compressed message flag set. Some
implementations will choose to compress the payload even when the output
size if larger than the input.
* response payload bodies are sized (in order): 31424, 61632
* response payloads are COMPRESSABLE
* if `request_compressed_response` is false, the response's messages MUST
NOT have the compressed message flag set.
* if `request_compressed_response` is true, the response's messages MUST
have the compressed message flag set.
* response payload bodies are sized (in order): 31415, 58979
* clients are free to assert that the response payload body contents are
zero and comparing the entire response messages against golden responses
### ping_pong
...
...
@@ -910,13 +872,6 @@ When the client requests COMPRESSABLE payload, the response includes a payload
of the size requested containing all zeros and the payload type is
COMPRESSABLE.
### Uncompressable Payload
[
Uncompressable Payload
]:
#uncompressable-payload
When the client requests UNCOMPRESSABLE payload, the response includes a payload
of the size requested containing uncompressable data and the payload type is
UNCOMPRESSABLE.
### Echo Status
[
Echo Status
]:
#echo-status
When the client sends a response_status in the request payload, the server closes
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment