본문 바로가기

진리는어디에

Reference list

일반적으로 스켈레톤이 reference count 대신 자신을 가리키는 프록시의 reference list를 유지한다. Reference list는 다음과 같은 특징들을 가진다 :

  • Reference list가 이미 프록시에 대한 정보를 가지고 있다면 프록시 정보 추가 요청에 대해 아무런 오퍼레이션도 하지 않는다.
  • Reference list에 프록시에 대한 정보가 없다면 프록시 정보 삭제 요청에 대해 아무런 오퍼레이션도 하지 않는다.
  • 위와 같은 특성을 idempotent하다고 하며, 한글로는 '멱등'의 뜻을 가지고 있다.

Reference list의 경우에는 신뢰성이 없는 분산시스템에서 사용하기 적합하며 이유는 아래에서 살펴보도록 하자.

Create
프로세스 p가 객체 o에 대한 remote reference를 만들면, 정상적으로 등록되었다는 응답이 올 때까지 계속 프로세스 p의 identification을 등록 요청하는 메시지를 전송한다. 그리고 삭제도 위와 비슷하다. 결과적으로 신뢰성이 없는 분산시스템에서 사용하기 적합하며, 중복 메시지에 대한 체크가 필요 없다. 이와 같은 reference list방식은 Java RMI에서 사용되고 있다.

Copy
프로세스 p1에서 p2로 레퍼런스를 복사한다면 :
  • p2는 객체 o의 스켈레톤에게 지속적으로 reference list에 등록 할 것을 요청
  • Ack가 도착하면 p2는 자신의 메모리 영역에 프록시를 생성한다.

Problem
프로세스 p1이 p2가 객체 o에게 레퍼런스 추가 요청을 하기 전에 자신의 레퍼런스를 삭제할 때 문제가 발생한다.

장점
비신뢰 분산시스템에서 failuer에 강하다. 스켈레톤은 주기적으로 프록시가 살아있는지 체크하는 ping을 보내고, 몇 번 시도후에 응답이 없으면 reference list에서 삭제한다.

단점
확장성에 안 좋음. 이것을 해결하기 위해 스켈레톤은 한정된 시간동안만 레퍼런스를 유지하고, 시간내에 갱신되지 않으면 reference list에서 삭제한다.

유익한 글이었다면 공감(❤) 버튼 꾹!! 추가 문의 사항은 댓글로!!