Yeah, SCTP would only be practical within a datacenter.
QUIC sounds like it should have a lot of the same benefits, but it also looks incredibly immature for those of us outside the Googleplex. There are only C++ bindings, even the Go bindings are experimental, and no real examples. There was a Netty thread discussing QUIC for Netty 5, but the people working on it gave up from lack of docs. I think the only practical solution for the near future would be to use libquic via JNI, and at that point the performance benefits might not be as large.
On Tuesday, December 15, 2015 at 12:07:46 PM UTC-8, Eric Anderson wrote:
I've not heard any discussion around using SCTP, although SCTP has a lot of nice features for our use. I thought SCTP still had problems over the Internet, but getting it working in a data center may not be too bad. Or maybe tunnel over UDP.
I've mostly heard people talking about wanting to try out QUIC, which already has an encryption story and HTTP semantics.
Hi all,
I'm wondering what the community's thoughts are about grpc over SCTP.
My understanding is that HTTP2 and SCTP already do some of the same things, for example streams to avoid head of line blocking. HTTP2 does it in the application layer, SCTP in the transport layer. My intuition tells me that for high-volume low-latency applications, the transport layer approach would be preferable.
For grpc-java, it looks Oracle includes an SCTP stack since Java 7, and Netty has SCTP channels.
Is this something with potential?
-Adam
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.