4 ms·

Not the GP, but I think the confusion stems from comparing TCP to RPC as if they are at odds with each other. TCP (Transmission Control Protocol) is a delivery

Not the GP, but I think the confusion stems from comparing TCP to RPC as if they are at odds with each other. TCP (Transmission Control Protocol) is a delivery protocol (i.e. how can we have a conversation between two places). RPC (Remote Procedure Call) describes how the messages should be treated (i.e. how each side should talk). So, RPC vs TCP doesn't make sense, even just looking at their names; a new protocol designed for RPC (maybe an RPCP) vs RPC over TCP does make sense.

sophacles 4y ago
This is just a name collision. Rpc in this context (that is transport layer protocols) just means a request /response pattern. A better category name would be nice. (Compare middleware - it's a concept that is pretty broad and has a lot of meanings over time but has been coopted to a subset that tends to mean "parse http headers and do things before the main endpoint handler")
- cryptonector 4y ago
  It's a misnomer, really. HTTP is request/response. If you want a non-TCP request/response protocol, QUIC is quite good. > A better category name would be nice. Sure, but if QUIC is good enough, then we don't need a new category name yet.
  - deleted 4y ago
    [deleted]
cryptonector 4y ago
In earlier posts on this topic (HOMA) we saw that TFA wants a new upper layer protocol to replace TCP and which is strictly a request/response protocol. They call that an RPC. RPC is a misnomer that invites all sorts of quibbling, so they would do better to not call it an RPC. New ULPs have trouble getting deployed due to bad middleboxen. It can work in a data center, but you have to deal with provisioning carefully when you opt to toss the congestion control belt and suspenders. More importantly, QUIC exists and is probably good enough, and without evidence that it's not I find HOMA and similar proposals to be possibly premature optimization.

sophacles 4y ago

This is just a name collision. Rpc in this context (that is transport layer protocols) just means a request /response pattern. A better category name would be nice. (Compare middleware - it's a concept that is pretty broad and has a lot of meanings over time but has been coopted to a subset that tends to mean "parse http headers and do things before the main endpoint handler")

cryptonector 4y ago
It's a misnomer, really. HTTP is request/response. If you want a non-TCP request/response protocol, QUIC is quite good. > A better category name would be nice. Sure, but if QUIC is good enough, then we don't need a new category name yet.
- deleted 4y ago
  [deleted]

cryptonector 4y ago

In earlier posts on this topic (HOMA) we saw that TFA wants a new upper layer protocol to replace TCP and which is strictly a request/response protocol. They call that an RPC. RPC is a misnomer that invites all sorts of quibbling, so they would do better to not call it an RPC. New ULPs have trouble getting deployed due to bad middleboxen. It can work in a data center, but you have to deal with provisioning carefully when you opt to toss the congestion control belt and suspenders. More importantly, QUIC exists and is probably good enough, and without evidence that it's not I find HOMA and similar proposals to be possibly premature optimization.