1. Structured P2P : Chord

노드들이 Ring 형태로 Overlay network을 구성한다.
각 노드는 해시함수를 돌려 id를 사용해, 데이터를 저장하고 찾을 수 있다.

위 상황의 경우, 4번 노드는 1번,7번과 연결되어 있고,
본인이 2,3,4의 데이터를 저장하고 있다.

Membership management

피어들은 계속해서 꺼졌다가 다시 켜졌다가 할텐데, 이를 어떻게 관리할 것인가? 에 대한 문제다.

ex. 새로운 노드가 참여할 경우

• 해시함수를 돌려 id를 지정 => 13이 나왔다!
  (bit 수를 크게 하면 겹칠 일 거의없음)

• id를 가지고 lookup => 현재 13을 가지고 있는 15의 주소를 알게 됨 (Successor)

• 15에게 '나 껴줘 요청' (Presuccessor인 12에게도 요청)

• 13인 내가 가져야할 데이터를 15에게 받아 옴.

ex. 완전히 연결을 끊는 경우

• 본인 peer들에게 알려 Successor-Presuccessor 끼리 연결하게 함
• 이렇게 안 알리고 나갈수도 있기에, 주기적으로 이웃 연결 확인해야
• 본인 데이터를 Successor에게 전달

2. Unstructured P2P

구조가 없기에, 랜덤 알고리즘이 많이 등장.

• 임의의 피어는 임의의 neigbor들과 연결됨 (= 이웃리스트를 가짐)
• 데이터가 어떤 노드가 가지고 있는지 알기 어려움
  - 이 데이터가 어딨는지 어떻게 찾지 ? => Broadcasting (비효율적)
  

Membership management

주기적으로 이웃들과 이웃리스트를 공유하면서 업데이트

SuperPeer

완전 동등한 구조로는 한계가 있기에,
역할이 많은 리더의, 슈퍼피어 노드를 도입할 수 있음.

이들을 뽑는 과정은 '노드 간 합의 후 결정' 되며, Leader Selection 알고리즘을 통해 결정.
슈퍼피어는 인덱스 정보를 가질 수도 있고, 약간의 서버 역할을 함
(어떤 데이터를 누가 가지고 있는지 등)

역할

• 새로운 노드가 Join 할 때마다 연결해서 껴주기
• 서버 역할을 하니, 금방 나가는 애들이 아닌, Long-lived Process한 애들중에 정해야됨. 알고리즘에서 이걸 고려해야.

3. Hybrid architecture

클라이언트-서버 구조, p2p구조의 장점들만 쓰자.

• 통신 : p2p
• 서버를 두고, 피어를 찾을 때 등 활용하자.

BitTorrent

"웹서버"로 부터 torrent 파일을 다운받고,
파일 안에 특정 파일을 다운하기 위한 정보가 들어 있다.
"트래커"는 요청한 파일의 청크를 가진 활성 노드를 계산하는 서버로,
이들이 알려준 노드들로 부터 파일을 다운로드 받는다.
그리고 다운로드 받는 동시에 본인도 가지고 있는 파일을 다른 이들에게 제공할 수 있다.

Middleware vs Architecture

미들웨어는 대부분 특정 아키텍처를 사용해, 상황에 따라 유연하게 최적화되지 않는 단점이 있다.
App에 필요에 따라 유연한 기능을 제공하는 아키텍처가 좋은 아키텍처이다.

Self-management

분산 시스템은 실행하면서 Automatic하게 자가진단을 통해 Adapting을 하면 좋을 것이다.
Monitoring => Analizing => Change Behavior
하는 시스템을 개발하는 것이 이상적이다.