Figma의 multiplayer technology works

Figma의 multiplayer technology works

와 같은 구조를 갖고 있다고 생각할 수도 있고, 또 다른 방법은 ObjectID, Property, Value 와 같은 튜플을 저장하는 행을 가진 데이터베이스로도 생각할 있습니다. 이런 맥락을 바탕으로 피그마에 새로운 기능이 추가된다는 것은 객체에 new properties가 추가된다고도 생각할 수 있겠다. 1. 객체 속성 동기화하기 Syncing object properties 피그마의 멀티플레이어 서버는 클라이언트가 특정 객체의 특정 속성에 보낸 최신 값을 추적합니다.

이는 서로 다른 두 클라이언트가 동일한 객체의 서로 다른 속성을 변경하면 충돌이 발생하지 않으며, 두 개의 클라이언트가 서로 다른 객체의 동일한 속성을 변경해도 충돌이 발생하지 않습니다.

Syncing trees of objects

객체는 최종적으로 일관된 트리 구조로 정립되어 있어야 합니다. 트리 구조를 설계할 때 목적으로 한 아래 두 가지를 살펴보시면 어떠한 방식으로 동작해야할지 유추할 있습니다. 1. 객체의 속성 변경과 reparenting 구조 변경, 부모 재조정이 충돌해서는 안됩니다. 누군가가 객체의 색상속성의 예시을 변화하는 동안 타인이 객체를 reparenting하는 경우, 이 두 작업은 모두 성공해야 합니다.

각각의 노드는 고유하다 2. 일제히 동일한 객체에 대한 두 개의 reparenting 작업은 트리의 다른 경우에서 두 개의 복사본이 생성되는 일이 무조건적으로 없어야 합니다. reparenting 작업은 충돌 발생이 가능한 경우, resolve 해주고 하나하나씩 클라이언트가 갖고 있는 복사본은 서로 같은 상태를 갖고 있어야 합니다.

Syncing object creating and removal

객체 생성과 객체 삭제는 명시적으로 동작하는데, 먼저 객체를 삭제하게 되면 해당 객체에 대한 모든 데이터, 즉 모든 속성이 서버에서 삭제됩니다. 서버에서 삭제된 대신 이 데이터는 삭제를 수행한 클라이언트의 undo 버퍼에 저장되고, 그 클라이언트가 삭제를 취소하려면 삭제된 객체의 모든 속성을 복원해야만 되는 책임이 있습니다. 정확히는 있다고 봄

생성에 있어서는 두 개의 클라이언트가 동일한 객체 ID를 가지면 안되므로, 모든 클라이언트에게 하나의 ID를 할당하고 새로 제작된 객체 ID의 일부로 의뢰인 ID를 포함시켜 중복을 방지할 있습니다.

Implementing undo

멀티플레이어 경우에서 undo처리는 꽤 복잡할 있습니다. undo에 대한 행동 정의는 싱글 플레이어 모드에 대해서는 꽤 자연스럽지만 멀티플레이어 환경에서의 undo 과정은 어떤 행동을 해야하는지도 꽤 혼란스러울 수 있을 것 같다. 만약 다른 사람들이 저희가 편집하고 실행 취소한 같은 객체를 편집했다면, 무슨 일이 일어나야 할까? 우리의 이전 편집이 그들의 나중 편집 위에 적용되어야 할까? 혹은 재실행에 대해서는 어떠한 방식으로 할까? 정하기 나름이라고 생각하지만, 첫째 내가 한 action에 대해서만 undo와 redo를 행하는 게 주요하다고 생각했습니다.

내가 한 것을 되돌리는 것 예를 들어, 저희가 어떤 텍스트를 쓰고 타인이 그 텍스트의 색상을 변경했다고 생각할 수 있는 경우에서 저희가 실행 취소를 하면 내가 작성한 텍스트가 사라지지만, 색상 변경은 그대로 남아있을 것입니다.

자주 묻는 질문