I spent more time than I would like investigating an issue caused by packet corruption in the past [1]. As a result, I am a firm believer that protocols carrying "important" data should be checksummed. In your case: If you are using SSL, that protocol itself carries strong cryptographic hashes over the data, which serves the same purpose. If corruption occurs, it is likely the SSL protocol will cause a connection break, but your application will not receive corrupt data. I would consider this sufficient.
[1] http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html On Wednesday, November 15, 2017 at 2:43:43 PM UTC-5, agup...@slb.com wrote: > > Hi, > > Does gRPC out of the box provide any guarantees for packet integrity over > the network? Do we need to implement CRC or checksum as a field in the > protobuf spec and use that to ensure that no packet corruption happened? > > This is in content of gRPC with Google cloud endpoints (ESP) if that > matters. Also, SSL is enabled between client and ESP. > > -Abhishek > -- 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/ad6c1af4-4b7c-43c6-a3bf-96602c4aa086%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
