Redesign Rust networking progression

[brson]

As discussed in #10, hyper no longer has synchronous APIs, so if we're going to have project 3 and 4 using synchronous networking we need a new plan.

cc @sticnarf

[sticnarf]

As @nrc mentioned in #7 , teaching hyper might not help much with pingcap's work. Moreover, I am afraid that it might be difficult for students to experience the difference between sync and async networking if we use a library like iron or hyper.

Can we just use TCP with an app layer protocol designed by ourselves, then use std::net for sync networking and tokio tcp for async networking? At this moment, if we limit the function to get and set, the protocol can be quite simple. If we need to add more functions later, we can introduce gRPC then.

[brson]

Oh, and if we did ask them to write the protocol, if they are clever they will use serde to serialize commands, as they learned in project 2. They can probably even use the exact same command structures for the protocol as they use to write to disk.

The other suggestions I've heard:

• Use hyper in a simple way that doesn't need futures, maybe even blocking on the futures to make it synchronous.
• Go straight to async in project 3 with hyper

At this moment I'm feeling good about @sticnarf's suggestion, but I think we need to bounce it off @siddontang since he and I decided on hyper last week.

@siddontang hyper doesn't have a sync mode and we're considering alternatives for project 3, which is planned to be about sync networking. @sticnarf suggests that we have them write their own simple protocol, which sounds reasonable to me. It gives more networking experience than relying on hyper.

[brson]

@nrc wrote some useful user stories in #24 (comment), and they make me worry that asking students to write a simple networking protocol may be too simple. CS students will probably have done some basic TCP work. Rust socket apis are not particularly interesting, and they are easy to find.

[brson]

Right now project 3 creates a custom protocol, and I think we will switch to hyper in project 5. From there I have some notion of a project 6 that moves to grpc.

I don't have any better ideas presently so closing.