P2P architecture VS Server-client architecture
- Server-Client Architecture
- 각 클라이언트는 파일을 받기 위해 서버와 TCP 연결을 맺습니다.
- 서버는 모든 파일을 업로드하고, 각 클라이언트에게 별도로 전송합니다.
- 파일 배포 시간: (클라이언트 수 * 파일 크기) / 업로드 속도
→ NF/u- 클라이언트가 파일을 다운로드하는 데 걸리는 시간: 파일 크기 / 다운로드 속도 (F/d)
- P2P architecture
- 파일을 갖고 있는 컴퓨터는 복사본을 업로드 → F/u
- 클라이언트는 파일 사본을 다운로드 → F/d
- 결론
- 서버-클라이언트 아키텍처에서는 서버가 모든 클라이언트에 파일을 전달해야 하므로 서버 부하와 대역폭 사용이 늘어난다.
- P2P 아키텍처에서는 파일을 갖고 있는 서버 컴퓨터가 파일의 복사본을 업로드하면 각 클라이언트가 이 복사본을 다운로드할 수 있으므로 파일 배포 시간을 줄일 수 있다.
Server-client 장점: 서버-클라이언트 모델은 중앙 집중 관리와 제어가 필요한 많은 응용 프로그램 및 서비스에 적합하다.
- 중앙 집중 관리: 서버-클라이언트 모델은 서버가 중앙에서 모든 파일을 관리하고 제어하는 구조로 파일의 무결성, 보안 및 업데이트를 중앙에서 쉽게 관리하고 제어할 수 있다.
- 신뢰성: 서버는 데이터 백업 및 복구를 수행하고 데이터 유실을 방지하기 위한 조치를 취할 수 있다.
- 고성능 서버: 서버-클라이언트 모델에서 서버는 고성능 하드웨어 및 전문적인 구성으로 구축될 수 있으며, 클라이언트는 더 경량화되어 간단하게 유지될 수 있다.
torrent: 파일 청크를 서로 교환하는 피어 그룹
토렌트 파일 공유를 위한 방식
- tracker: 중앙 집중식 서버 사용하여, 토렌트 네트워크에 참여하는 피어들의 목록을 유지
- 새로운 사용자가 네트워크에 참여하면 해당 사용자에게 피어 목록을 제공
- 새로운 사용자는 파일 청크 목록을 다른 피어들로부터 요청
- DHT (Distributed Hash Table): 분산 해시 테이블을 사용하여 토렌트 파일과 피어 정보를 저장하고 검색하는 방식
- 해시 계산: 파일을 공유하려는 사용자는 파일의 내용을 해시 함수를 사용하여 해시값으로 변환하여 해시 테이블에 저장
→ 파일 내용에 대한 해시값과 해당 데이터 위치 정보 저장- 검색: 다른 사용자가 파일을 검색하면 해당 파일의 이름 또는 내용을 해시 함수를 사용하여 해시값으로 변환
→ 이 해시값을 DHT 해시테이블에 요청- 데이터 전달: DHT 노드가 해당 해시값을 찾으면 데이터를 검색한 사용자에게 반환
Requesting chunks(rarest first): 청크를 요청할 때 가장 적은 복사본을 가진 청크를 우선적으로 선택하여 요청
→ 토렌트 네트워크 내에서 파일 조각을 효율적으로 분배하고, 모든 사용자가 파일 조각을 고르게 받을 수 있도록 도와준다.
Sending chunks(tit-for-tat): P2P 토렌트 네트워크에서 어떤 피어에게 청크를 전송할 때 어떤 순서로 결정할지를 나타내는 방식
- 현재 나에게 가장 많은 청크를 보내주고 있는 피어 사용자 4명을 선택하고, 이들에게 우선적으로 청크를 전송
- 일정한 간격(예: 10초)으로 현재 가장 많은 청크를 보내주고 있는 4명의 피어 사용자를 재평가하고 갱신
→ 나머지 피어들은 chunk를 받지 못한 choked 상태- 매 30초마다 무작위로 하나의 피어를 선택하고, 이 피어에게 chunk를 전송
→ optimistically unchoked