왜 P2P가 필요한가? ¶
장단점 ¶
- 개인위키 사용이 용이하다.
- 웹기반이 아니기 때문에 더 편한 입력 방식을 개발할 수도 있다.
- 그러나 접속하기가 귀차니즘해지고 어려워진다. 프로그램을 설치해야 하므로.
- 그러나 접속하기가 귀차니즘해지고 어려워진다. 프로그램을 설치해야 하므로.
- WikiWiki가 아닐수도 있다.
- WikiWiki의 기본정신인 FourAsOfWiki을 위배하는 격이 아닌가?
- 접속할 수 있는 단말기의 수가 훨씬 제한된다. anywhere에서 언급한 인터넷에 접속할 수 있는 곳이라면 에서 벗어난다.
인터넷과 웹브라우저가 보급되기 전에는 "anywhere you can access to the internet"이라고 할 수는 없었을 것입니다. 그리고 많은 위키엔진이 하나의 운영체제와 웹 브라우저에만 기울어져 있기 때문에 그것도 엄밀히 말하면 anywhere라고 할 수 없습니다. P2PWiki 소프트웨어가 있다면 그것을 대대적으로 배포하면 anywhere가 될 수 있을지도 모릅니다. FourAsOfWiki는 해석하기 나름이며, 문제는 "P2PWiki가 WikiWiki로 존재하려면 어떤 형태로 존재해야 하는가"인 것 같습니다. --PuzzletChung
P2PWiki가 WebBrowser보다 더 보급되기는 힘들어보입니다.png ":)")
. -- 최종욱
- 접속할 수 있는 단말기의 수가 훨씬 제한된다. anywhere에서 언급한 인터넷에 접속할 수 있는 곳이라면 에서 벗어난다.
- WikiWiki의 기본정신인 FourAsOfWiki을 위배하는 격이 아닌가?
개발 관련 ¶
- 자신이 생성/변경한 페이지의 정보를 모든 접속자들에게 전송한다.
- 받은 정보는 즐겨찾기인 경우에 하드에 영구 저장하고 즐겨찾기가 아닌 경우에는 일정 기간 또는 허용된 용량 안에서만 저장하며, 하드에 저장된 동안에는 다른 접속자들에게 재전송한다.
특정 페이지를 즐겨찾기에 넣는 것이 귀찮아질 경우가 있다. 페이지에 한 번 들렀던 적이 있다면 즐겨찾기에 자동으로 등록되고, 날짜 순으로 오래된 것은 밀려나고... 이게 낫지 않을까?
- 즐겨찾기에 들어있는 페이지가 바뀌면 알려준다. 페이지 온도를 설정해두면 이 온도에 따라 알려주는 주기를 달리할 수 있다.
- Linux, Windows, Mobile 환경의 프로그램을 개발하거나 자바 애플릿을 사용해야 할 것이다. - see also 모바일위키
- 다큐먼트모드에서는 동시에 한 페이지가 편집되었을 경우 문제가 생긴다. 쓰레드모드라면 괜찮지 않을까? -- 쓴귤, 최종욱
P2PWiki의 불안정성 토론 ¶
- 순수 P2PWiki는 불안정하다. P2PWiki는 네트워크가 분리될 경우, 시간에 따라 접속자 구성이 달라진다. 그들이 가진 정보가 P2PWiki의 정보를 이룬다. 따라서 접속자 구성에 따라 정보의 구성도 바뀐다. 다시 말해, 시간에 따라 정보의 구성이 바뀐다. anytime과 anything에서 벗어났다고 볼 수도 있다.
- 효율이 떨어지는 HybridP2P로 안정화할 수 있다. 클라이언트의 목록을 제공하는 서버를 갖춘 HybridP2P 시스템을 이용하면 네트워크가 분리되는 PureP2P 시스템의 문제를 막을 수 있다. 하지만 이렇게 되면 이전의 client-server 시스템과 다를 것이 하나도 없을 뿐 아니라, 효율이 더욱 떨어지는 셈이다.
- 네트워크 분리가 일어날 가능성은 작다. 한 노드가 평균적으로 10개의 노드와 연결되어 있는 무작위 네트워크를 가정하자. 각 노드는 매 시간 1/2의 확률로 켜져있거나 또는 꺼져있다.
- 한 시점에 1개의 노드 주변의 모든 노드가 꺼져있을 확률 : (1/2)^10 = 0.1%
- 한 시점에 2개의 연결된 노드 주변의 모든 노드가 꺼져있을 확률 : (1/2)^18 = 0.003%
- 한 시점에 3개의 연결된 노드 주변의 모든 노드가 꺼져있을 확률 : (연결된 위상에 따라 확률이 달라진다)
위에서 보인 바와 같이 크기가 큰 "분리된 네트워크"가 존재할 확률은 극히 적다. 크기가 작은 "분리된 네트워크"는 비교적 자주 발생한다. 이 경우 문제가 되는 것은 어쨌든 이 분리된 네트워크에서 한 페이지가 변경되고, 다른 분리된 네트워크에서 또 한 페이지가 변경되었을 경우이다. 이 경우 두 네트워크의 분리가 해소되는 순간 이 둘을 통합하면 된다. 간단히 말해, 두 "변경사항"을 통합하면 된다. 이런 통합된 변경사항이 많은 문서는 문서구조조정을 통해 다시 깨끗하게 처리될 수 있다. - 한 시점에 1개의 노드 주변의 모든 노드가 꺼져있을 확률 : (1/2)^10 = 0.1%
- 방문한 페이지만 저장하는 체계'에서 정보의 신뢰도는 떨어진다.''' 예를 들어, 이용자C가 페이지1,2,3을 다음과 같이 연결하여 만들었다고 하자. 그러면 다음과 같은 상황이 된다. 이 문제는 HybridP2P로도 해결되지 않는다.
{{|페이지1 - 페이지2 - 페이지3|}}
이용자A가 페이지1을 방문하고, 이용자B가 페이지3을 방문한다.
{{|이용자A -> 페이지1 - 페이지2 - 페이지3 <- 이용자B|}}
이용자C와 이용자A가 네트워크를 떠났다. 이용자B는 페이지2의 내용에 접근할 수 없으며, 페이지1은 존재하는지 여부조차 알 수 없다. 여기서 이용자B가 임의대로 페이지1,2를 생성했다고 치자. 그렇다면 나중에는 완전히 다른 판본의 문서들이 생긴다. 따라서 문서구조조정을 자동으로 할 수도 없다.
- P2PWiki의 정보의 신뢰도를 시물레이션 해보자. 한 이용자가 5%의 (노스모크 현재 기준 5000페이지중 250페이지) 무작위적 정보를 저장한다고 가정하자. 그리고 평균 10명 정도가 접속해있다고 하자. 다음의 VisualBasic6 소스를 이용하여 시물레이션 하면 전체 정보의 40%에 미치지 못하는 결과가 나온다(많은 오류가 있으니 FixMe). 절반도 저장하지 못하는 셈이다. 한사람당 500페이지씩 저장을 한다고 가정했을 때 비로소 60%에 달하는 결과가 나온다. 그래도 신뢰하기 힘든편이다.
Dim data(5000) For a = 1 To 10 For b = 1 To 250 data(Int((5000 * Rnd) + 1)) = 1 Next Next b = 0 For a = 1 To 5000 If data(a) = 1 Then b = b + 1 Next MsgBox b / 5000 * 100 & "%" - 개발관련에서 언급한대로 변경된 페이지 정보를 전송하게 하면 위의 문제는 풀 수 있다. 이용자C가 페이지3개를 시점 T2에 P1, P2, P3를 생성했다고 하자. 시점 T1에 접속했던 이용자 A, B가 시점 T3에 접속하면 이들은 페이지 3개를 모두 받는다. WikiWiki라기보다는 WikiWiki 타입의 문서를 전송하는 NewsBroadcastingSystem 일지도 모르겠다. 그렇다면 굳이 WikiWiki 형태로 만들 필요가 있을까? "없다"
제안입니다. 서버에 클라이언트 목록 대신 페이지별 최근 수정 시각만을 저장하게 하면 어떨까요? 그렇게 된다면 다음과 같은 경우에 다음과 같이 하면 됩니다.
- (서버가 인정한) 최근의 페이지를 수정했을 경우 (->) 서버의 최근 수정 시각을 업데이트한다.
- 사용자가 클라이언트에는 있지만 최근이 아닌 페이지를 봤을 경우 (->) 최근의 페이지로 업데이트할 때까지 수정을 못 하게 한다.
- (서버가 인정한) 최근 수정 시각을 확인하고, 수정했지만 그 순간 최근 수정 시각이 달라져 있을 경우 (->) 필시 동시수정이다.
- 두 명이 같은 페이지를 동시에 만들었을 때에도 (->) 동시수정.
Kazaa처럼 Upload 대 Download로 사용자 별로 점수를 매기는 것도 생각해 볼 만 하겠네요.
