IPFS 데이터 교환 계층-GetBlocks

데이터 교환 계층이 상위 프로토콜에 대해 제공해야 하는 기본 기능을 알아보고자 합니다. 우선 IPFS의 교환 계층 인터페이스 설계는 다음 위치에서 확인할 수 있습니다.

IPFS exchange interface (interface.go)

// Package exchange defines the IPFS exchange interface
package exchange

import (
	"context"
	"io"

	blocks "github.com/ipfs/go-block-format"
	cid "github.com/ipfs/go-cid"
)

// Interface defines the functionality of the IPFS block exchange protocol.
type Interface interface { // type Exchanger interface
	Fetcher

	// TODO Should callers be concerned with whether the block was made
	// available on the network?
	HasBlock(blocks.Block) error

	IsOnline() bool

	io.Closer
}

// Fetcher is an object that can be used to retrieve blocks
type Fetcher interface {
	// GetBlock returns the block associated with a given key.
	GetBlock(context.Context, cid.Cid) (blocks.Block, error)
	GetBlocks(context.Context, []cid.Cid) (<-chan blocks.Block, error)
}

// SessionExchange is an exchange.Interface which supports
// sessions.
type SessionExchange interface {
	Interface
	NewSession(context.Context) Fetcher
}

데이터 교환 계층이 상위 계층 프로토콜을 위해 제공해야하는 기본 기능을 결정하는 위 코드는 IPFS의 스위치 계층 인터페이스 설계이며 데이터를 검색하고 데이터를 교환하는 기능을 제공하기 위해 특정 스위치 계층 구현자를 필요로 합니다.

  • GetBlocks: 지정된 키 세트에 해당하는 데이터 인터페이스를 가지고 옵니다.

GetBlocks interface 단계

위의 그림은 GetBlocks() 인터페이스의 첫 번째 단계로, 키 집합에 해당하는 데이터 요청을 데이터 교환 계층의 여러 구성 요소로 전송하여 각 모듈에 새 작업이 도착했음을 알립니다.

먼저 모든 키를 Pub/Sub 모듈에 건네고 모든 키를 알림 대기열(Notification Queue)이라는 구독 큐에 추가합니다. 이 구독 큐는 파이프 그룹이며 파이프 그룹의 길이는 키 수에 의해 결정됩니다. 이 파이프 라인 큐 관리는 순환루틴입니다. 가입 키에 대응하는 데이터 블록이 도착할 때마다, want list로 부터 삭제 요청이 생성되고, 위 그림의 절차 4에 도시 된 바와 같이, 획득 된 데이터에 대응하는 키가 want list로 부터 삭제된다.

두 번째 단계에서는 그룹 키가 요청 데이터 항목에 패키지화되어 Incoming Queue에 추가됩니다. 이는 고정 크기가 10인 요청 캐시이며 데이터를 가져 오기위한 요청과 데이터 요청 취소 요청을 저장하는 데 사용됩니다. 이 대기열의 사용은 계속해서 다음 섹션에서 설명합니다. 그의 역할은 데이터에 대한 캐시 요청으로 작동하는 것입니다.

세 번째 단계에서이 키 집합의 0 번째 요소는 findkeys Queue의 요소로 삽입되며 큐의 길이는 32 고정 크기입니다. 이 큐의 상세한 사용은 다음에 상세하게 설명합니다.

다섯 번째 단계는 Incoming Queue에서 작업을 제거하고 작업 유형을 결정하는 것입니다. 데이터의 ID에 따라 Key-Value 맵이 있습니다. 맵의 각 항목은 메시지 대기열입니다. 작업 유형이 증가하면, 작업 유형으로 전달 된 키를 대기열에 추가하고, 삭제 된 경우 키에 따라 메시지 대기열에서 데이터를 삭제하는 방법은 다음과 같습니다. 이 단계에서 사용 된 실행 루프는 두 가지 유형의 원하는 목록에서 작동해야한다는 점을 지적해야합니다. 하나는 normal want list이고 다른 하나는 broadcast want list입니다. broadcast want list는 질의 노드없이 키 데이터를 저장합니다. normal want list는 이니시에이터가 고정 키 배열을 찾기 위해 지정한 질의 노드 객체를 찾습니다.

Findkeys Queue 루틴

normal want list에는 Findkeys Queue에 가입하기 위해 목록에서 임의로 키를 선택하는 동시 루틴 타이밍이 있습니다. Findkeys Queue에는 이 큐를 관리하기 위한 순환이 있습니다. 이 큐는 요소 중 하나를 사용하고 데이터 교환 프로토콜에 액세스합니다. 네트워크 인터페이스는, 어떤 노드가 요소에 대한 데이터 (요소의 데이터에 해당하는 키 값)를 제공 할 수 있는지 쿼리하고, 네트워크 인터페이스는 해당 라우팅 계층을 호출하여 해당 노드를 찾습니다.

네트워크 인터페이스는 키에 대한 데이터 공급자 목록을 반환합니다. 이 목록에 저장된 요소는 Peer Info입니다. 이 정보는 네트워크 계층 (네트워크 레이어 - 라우팅 레이어 - 파일교환 레이어 순서)에 사용됩니다. 데이터 연결에 대한 기본 정보를 설정합니다. 데이터 교환 층은 데이터 교환 층과 네트워크 층 사이의 네트워크 링크 정보를 관리하는 호스트 객체를 갖는다. 이 개체를 통해 데이터 교환 계층은 반환 된 모든 네트워크 계층 노드와 직접 연결됩니다.

요약하면이 섹션에서는 주로 GetBlocks() 인터페이스 명령을 받아들이는 노드의 처리 흐름을 분석합니다.이 명령을받은 후에 노드는 명령을 캐시하고 네트워크 전체의 데이터 쿼리를 수행하도록 각 큐에 알리는 것에 중점을 둡니다. 관련 노드는 직접 네트워크 레이어 링크를 설정합니다. 다음 섹션에서는 데이터 수집 프로세스의 전체 과정이 데이터 공급자 또는 데이터 중계자의 관점에서 어떻게 구현되는지 분석합니다.