Hey Todd! I didn't know you frequented this list, I really appreciate the reply. Great talk by the way.
> To allow full async communication, the basic communication block must be simplex > (1-way) and not have response dependency at the application nor protocol level. Something similar to UDP then? How would we deal with reliability in that case? Otherwise, if you mean for levels higher up in the stack, how do we deal with error situations if we should not have a response dependency? A project I worked on previously used actors deployed in a pipeline manner, where each actor would receive data from the previous actor, process the data, then forward them on to the following actor. The main information flow at the data processing level was one-way; however, we still had to implement flow control with back-pressure awareness, which made the "control plane" part of the protocol be two-way. How would this fit into what you mentioned? > For example, an extremely common problem with some systems using REST is > throughput being restricted by RTT due to response coupling (application or > protocol). If I understand this correctly, what you're saying is that we won't be able to batch requests for example due to this tight coupling between requests and responses, among potentially other performance improvements as mentioned in the talk. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
