You could set request parameters as metadata for the file upload RPC. 
Server receives metadata before the streaming data is received.

On Wednesday, April 11, 2018 at 10:58:20 AM UTC-7, rSam wrote:
>
> I recently had to implement a similar solution to send files. I considered 
> these options:
> a) Your option, rpc call that sends back chunks
> b) RPC call that replies with a port number where the server will listen 
> for the file (or in your case, some other response to the rpc call, like a 
> file identifier that will be requested in other way)
> c) Do not use rpc calls, and use regular sockets for file transfers, 
> handling other types of communication via rpc
>
> After researching 'a)', and implementing 'b)', I ended up going back to 
> 'c)'. My server has two ports open, one for RPC calls, and one for FTP 
> calls. They are separate threads that know how to talk to each other, but 
> files are not served through RPC anymore.
>
>
>
>
>
> On Wed, Apr 11, 2018 at 9:51 AM, 'Eric Gribkoff' via grpc.io <
> grp...@googlegroups.com <javascript:>> wrote:
>
>>
>> Either approach could be appropriate: dividing the large message into 
>> chunks or sending it all in one message (note: gRPC has a default max 
>> message size that varies by language but can be configured). Which one 
>> performs best for your use case will depend on a number of other factors. 
>> There was some earlier discussion around this in 
>> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/grpc-io/MbDTqNXhv7o/cvPjrhwCAgAJ
>> .
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Tuesday, April 10, 2018 at 2:39:51 PM UTC-7, Weidong Lian wrote:
>>>
>>> Hello grpcs,
>>>
>>> I have the following task sent from client to server.
>>>
>>> service applis {
>>>   rpc GenerateVoxelMesh(VoxelMeshRequest) returns (VoxelMeshReply) {}
>>> }
>>>
>>> message VoxelMeshRequest {
>>>   any image_input = 1;
>>>   bool smooth = 4;        
>>>   int32 iterations = 5;   
>>>   double mu = 6;          
>>>   double lambda = 7;   
>>>   double scale = 8;      
>>>   repeat int32 part_ids = 9; 
>>> }
>>>
>>> message VoxelMeshReply {
>>>   any nas_output = 1; // text file
>>> }
>>>
>>> The image_input, nas_output are the binary files that can be fairly 
>>> large sometimes. I would guess the `any` is not a recommended type. 
>>> It is preferred to use stream chunk bytes to send and receive the image 
>>> and nas files. However, if we stream chunk file, we can not send
>>> the other request parameters at one call. We will have to make multiple 
>>> calls and make server side a state machine. It increases the complexity.
>>>
>>> I am just wondering if there any more element design or what the 
>>> idiomatic way of doing this in grpc? 
>>>
>>> the possible design like below.
>>>
>>> service applis {
>>>   rpc GenerateVoxelMesh(stream VoxelMeshRequest) returns (stream 
>>> VoxelMeshReply) {}
>>> }
>>>
>>> message VoxelMeshRequest {
>>>     oneof test_oneof {
>>>        FileChunk image_input = 1;
>>>        VoxelMeshParamters mesh_params = 2;
>>>     }
>>> }
>>>
>>> message FileChunk {
>>>  bytes chunk = 1;
>>> }
>>>
>>> message VoxelMeshParameters {
>>>   bool smooth = 4;        
>>>   int32 iterations = 5;   
>>>   double mu = 6;          
>>>   double lambda = 7;   
>>>   double scale = 8;      
>>>   repeat int32 part_ids = 9; 
>>> }
>>>
>>> message VoxelMeshReply {
>>>   FileChunk nas_output = 1; // text file
>>> }
>>>
>>> Any suggestion will be appreciated. 
>>> Thanks in advance,
>>> Weidong
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grpc-io+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to grp...@googlegroups.com 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/grpc-io.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/a4c82a7c-6542-4d51-be35-7c2b9e583dc9%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/grpc-io/a4c82a7c-6542-4d51-be35-7c2b9e583dc9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/5be2146f-19d2-4b1a-885b-f6270534cc20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to