I've been reading the section on framing in the tokio tutorial. In it, a trial-and-error technique is described to determine when a new Redis protocol frame has arrived. In other words, code checks if the data that has arrived so far constitutes a full protocol frame and processes it if so. If the frame is not complete, it'll repeat the checking process once more data has arrived. Depending on the packetization and buffering performed by lower layers this may add overhead (the amount of which is subject to debate for the common case.)
By contrast, in event-based programming we typically use a state machine so that protocol processing can advance with a single pass over the data received so far, see, for instance, the http parser used in nginx. In this style, once more data is received, the protocol state machine will continue in the middle of a frame where it left off rather than repeating the process of trying to find frame boundaries.
Why is the tokio mini-redis sample application in the tutorial not written in a similar event-based style? It would be my intuition that Rust's async support would allow that, in theory at least, are there other reasons for why this wouldn't work?
PS: a preliminary look at Hyper (the http engine that's recommended(?) with tokio) shows that it adopts the same approach.