深入理解Tokio——多路復用協議

本文原版本為官方英文文檔,詳情見官方http://tokio.rs

Amultiplexedsocket connection is one that allows many concurrent requests to be issued, with responses coming back in the order they are ready, rather than in the order requested. Multiplexing allows a server to begin processing requests as soon as they are received and to respond to the client as soon as the request is processed. Generally, multiplexed protocols will make better usage of available resources like TCP sockets.

多路復用socket鏈接允許同時并發多個請求,按照處理完成順序響應,而不是按照請求順序響應。多路利用允許一個服務只要請求一到達就開始處理這些請求,同時只要請求一處理完成應當響應。一般來說,多路復用協議更好的利用了像TCP socket資源。

Since responses arrive out of order, arequest IDis used to match responses with their associated requests. When the client issues a request, the request will be paired with an identifier. The server processes the request, and sends a response to the client paired with the same request identifier. This allows the client to match the response with the request that it issued.

因為響應到是無序的,所以使用request ID來匹配request和他的響應。當client發起一個請求時,這個請求和一個標識組合。這服務處理這個請求,發現響應的時候帶上相同的請求標識??蛻舳司湍芷ヅ涞桨l起請求的響應結果。

Flow of multiplexed requests and responses

多路復用請求和響應流程圖

Tokio makes implementing multiplexed clients and servers easy. This guide will show how.

Tokio使多路復用client和server實現變得更加簡單。具體見下面介紹:

Overview

Just as with theecho serverguide, implementing a client or server for a multiplexed protocol is done in three parts:

實現一個client和server多路復用分為三個步驟:

Atransport, which manages serialization of Rust request and response types to the underlying socket. In this guide, we will implement this using theframedhelper, just as before.

Transport,負責將Rust 請求和響應類型序列化到低層socket.這里,我們將使用framer helper實現

Aprotocol specification, which puts together a codec and some basic information about the protocol.

Protocol規范,將編碼器與一些協議基本信息組合到一起。

Aservice, which says how to produce a response given a request. A service is basically an asynchronous function.

Service,負責處理請求的響應邏輯。一個service一般是一個異步function。

Each part can vary independently, so once you’ve implemented a protocol (like HTTP), you can pair it with a number of different services.

每一部分都是獨立的,你一旦實現了一個協議(像http),你可以與其它的服務組合。

This guide specifically covers implementing asimplemultiplexed protocol. Thenext sectionwill show how to implement a streaming protocol.

本文包含實現一個簡單的多路復用協議。下一章展示如何實現一個stream協議。

The full implementation can be found in thetokio-linerepository. Let’s take it step by step.

Step 1: Implement a transport?

實現一個transport

In Tokio, atransportis any type implementingStream+Sinkwhere the yielded items are frames.

在Tokio,一個Transport 是一個實現了Stream+Sink?trait的類型,其生產的items都是frames

同樣,我們將實現line-based協議,不過這次是全雙工,是由frames組成的stream,每一個frame包含:

? ? ? ? ? ? 1、在網絡字節序中,頭4字節表示request ID。

? ? ? ? ? ? ?2、Frame payload,一個UTF-8編碼的不定長的字符串,以字符"\n"結束

注意,這些Line不支持包含轉義后的換行符。

使用tokio-proto全雙工后,我們的transport會變得復雜,frame將是由request Id和payload組件的元組構成的。

use tokio_proto::multiplex::RequestId;

type MyMultiplexedFrame = (RequestId, T);

TheT here represents the request or response type used for theService.tokio-protowill use theRequestIdin the frame to match outstanding requests with responses.

T 代表的是請求或響應的類型。tokio-ptoto將使用request id去匹配請求和響應。

Step 2:?實現Protocol

下一步是定義協議細節。

Step 3:實現服務

An interesting thing to note is thatRequestIddoes not show up as part of theService’s request and response types. TheRequestIdis only needed for tokio-proto to manage the internal state of keeping requests and responses matched when operating on the transport.

一個比較有意思的事情是Request ID 并沒有作為Service的Request和Response類型的一部分,Request Id只是被tokio-proto用來在transport上管理內部狀態和匹配request和response。

Again, you can find the full working example?here.

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容