I kinda agree with you. After googling and testing, the grpc may not be a proper tool to handle the client-server with tight logic, e.g. both sides are state-machines, like in desktop client and remote server. We can still use protobuf, but your own socket/websocket might be easier solutions than grpc.
grpc is a great tool to replace the REST APIs among microservices. Your option c) sounds reasonable, but adds complications to the whole system. On Wednesday, April 11, 2018 at 7:58:20 PM UTC+2, 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. > -- 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/0b0b58f5-febf-4732-acae-4f525207bb98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
