자주 문의하는 질문들
목차
저에게 적합한 Photon 제품은 무엇인가요?
이 질문에 답하기는 좀 까다롭습니다. 왜냐하면 이는 만들고 있는 게임과 프로젝트의 특성에 따라 달라지기 때문입니다. 하지만 다음과 같이 권고해드립니다:
- 시청 당사 CTO 와 설립자 Chris Wegmann 씨가 Unite Europe 2017 에서의 대화
- 비교 문서 읽어보기: "PUN vs. Bolt"
- 비교 문서 읽어보기: "Photon Cloud or Photon Server?"
Photon Realtime 과 PUN의 차이점은 무엇인가요?
Photon Realtime 과 PUN 모두 동일한 API 기반입니다: LoadBalancing API. 이 두 제품 모두 동일한 백엔드, 동일한 서버 어플리케이션, 동일한 저수준 기능, 동일한 핵심 개념을 공유합니다. 우선, PUN 은 더 좋은 UNet (이전 Unity Networking)이었습니다: 동일한 API를 유지하면서 더 견고한 백엔드와 더 많은 기능이 있습니다. 그후 천천히 발전하여 Unity에서 최고의 멀티 플레이어용 솔루션이 되었습니다.
우리에게는 Photon Realtime Unity SDK도 있으나 PUN에는 다음과 같은 고수준의 기본 제공 기능이 있습니다:
- Magic Unity 콜백
- 직렬화하고 동기화하는 추가 유니티 컴포넌트. 네트워크화된 객제: PhotonView 에서 가장 중요한 것 중 하나
- PunRPC
- 오프라인 모드
- ...
여기에서 더 자세히 알아보세요.
PUN 이 webhooks 와 룸 상대 지속을 지원하지만, 저장된 게임을 로드할 때 네트워크로 연결된 개체의 상태를 100% 다시 라우팅 할 수 없습니다. 여기를 자세히 읽어보십시오.
로드 밸런싱
Photon 룸이 지원하는 플레이어의 최대 수는 몇명인가요?
플레이어의 수는 룸내에서 트래픽을 증가시키는 주요 원인입니다. 플레이어가 많아질수록 더 많은 메시지들이 교환됩니다.
간단히 답변하면 다음과 같습니다:
4명이 좋으며, 8도 허용됩니다. 8명 이상은 까다롭고 약간의 네트워킹 코드에 기교가 들어갑니다.
상세히 설명하면:
이론상으로 말하면 제한은 없습니다. 8명 이상의 플레이어의 경우에는 관심 관리가 필요합니다. 다량의 플레이어에 대해서, 여러개의 룸을 통해 플레이어들을 분리 해야할 것 입니다.
Photon 문자열에는 제한이 있나요?
Photon은 룸 이름, 로비 이름, UserID, 별명, 사용자 지정 속성 키 등의 많은 목적으로 문자열을 사용합니다.
Photon 이진 프로토콜은 최대 32767 글자까지 직렬화할 수 있습니다. 이름과 사용자 ID의 경우 32자이면 충분합니다(예: GUID는 32 글자). 그러나 사용자 지정 속성 키의 경우에는 문자열을 짧게 사용하여 오버 헤드를 최소화해야 합니다. 이것은 로비에서 보여지는 속성들에 있어서 특히 중요합니다. 이러한 속성은 룸 목록의 일부이며, 룸에 있는 두명의 클라이언트뿐만 아니라 로비에 있는 모든 사용자에게 전송되기 때문입니다.
사용자 지정 속성의 갯수에는 제한이 있나요?
아닙니다.
하지만 사용자 지정 속성이 많이 설정되면 룸에 참여할 때 클라이언트들이 모든 속성을 수신하기 때문에 클라이언트 로드 시간이 더 길어지게 됩니다. 이러한 항목이 너무 많아 클라이언트의 로드 시간이 일정 시간을 초과하면 연결이 끊어질 수 있습니다.
Photon을 사용하여 매우 큰 메시지를 보낼 수 있나요?
하는 것에 대해 정확하게 알지 못하면, Photon을 사용하여 대용량 데이터(즉, 파일)를 전송하지 않는 것이 좋습니다. 교환하는 데이터를 최적화하고 정말로 큰 메시지를 보내야 한다면 당사로 연락 주시기 바랍니다.
Photon Cloud에는 서버상에 클라이언트용 버퍼에 대해 500KB로 제한하고 있습니다. 따라서 상황에 따라 메시지가 고려되어야 합니다:
- Photon Cloud > 500KB의 클라이언트 버퍼 크기에 비해 "너무 큼". 클라이언트가 짧은 시간 내에 이 제한에 도달하면 서버에 의해 연결이 끊어집니다.
- 100KB 보다 큰 문제를 일으킬 수 있는 많은 조각을 만들지 않고 UDP와 함께 보내기에는 "너무 큼".
- UDP 패킷이 > 1.2KB를 여러개로 분리하지 않고 전송하기에는 "너무 큼" (프로토콜 오버 헤드 포함).
주기적으로(초당 10회 또는 그 이상)발송되는 메시지의 경우, 크기를 1KB 미만으로 유지하는 것이 좋습니다.
메시지를 거의 보내지 않는 경우(예:경기 시작시 한번만 전송) 여러 KB의 크기는 괜찮지만 10KB 미만으로 유지하는 것이 좋습니다.
20KB 또는 50KB와 같은 예외적인 경우도 발생할 수 있습니다. 하지만 보통 그 정도로 큰 메시지는 뭔가 잘못되었다는 것이며, 다시한번 검토하여 선택한 사항을 재고해야 합니다.
어떤 데이터가 신뢰성있게 전송되며 신뢰성 없게 전송되는 데이터는 어떤것입니까?
무엇보다도, 프로토콜이 UDP인 경우에만 신뢰성이 있다는 것을 알아야 합니다. TCP에는 여기에서 다루지 않고 있는 TCP 자체의 "신뢰성" 메커니즘이 있습니다.
신뢰성 있게 전송한다는 것은 목표한 곳에 도착한다는 것을 확신한다는 것 입니다. 따라서 충분한 시간을 기다린 후에 잘 받았다고 회신을 받지 못한 경우에는 확인을 받거나 받을 때까지 다시 보냅니다. 또한 신뢰할 수 있는 이벤트를 반복하면 지연 시간이 길어지고 이후의 이벤트가 지연될 수 있습니다.
신뢰성을 사용하지 않은 예제:
- 실시간 게임에서 플레이어의 위치 변경
- 음성 또는 동영상 채팅
신뢰성을 사용한 예제:
- 턴 기반 게임의 턴 이벤트
게임에서 왜 자주 끊기나요?
연결해제는 다양한 원인에 의해서 발생될 수 있습니다. 이 문제에 관련된 사항에 대해 두 가지의 문서가 있으니 도움이 될 것 입니다:
- "연결해제 분석"
초당 메시지 룸당 메시지는 어떻게 계산되나요?
Photon 서버는 초당 총 인바운드 및 아웃바운드 메시지 수를 세고 전체 룸 수(동일한 마스터 서버에 있음)로 나눕니다.
모든 오퍼레이션 요청, 오퍼레이션 응답 또는 이벤트는 메시지로 간주됩니다. Photon 오퍼레이션은 선택적인 오퍼레이션 응답을 반환하고 0개 이상의 이벤트를 트리거 합니다. 캐시된 이벤트도 메시지로 계산됩니다.
룸 오퍼레이션에서의 메시지 비용:
| 오퍼레이션 | 성공: 최적 | 성공: 평균 | 성공: 최악 |
|---|---|---|---|
| Create | 2 (SuppressRoomEvents=true) |
3 + Join 이벤트 (SuppressRoomEvents=false, default) |
4 + ErroInfo 이벤트 (HasErrorInfo=true) |
| Join | 2 + k (SuppressRoomEvents=true) + k * 캐시된 커스텀 이벤트 |
2 + n + k + n * Join 이벤트 (SuppressRoomEvents=false, default) |
2 + 2 * n + k + n * ErroInfo 이벤트 (HasErrorInfo=true) |
| Leave | 2 (SuppressRoomEvents=true) |
1 + n + (n - 1) * Leave 이벤트 (SuppressRoomEvents=false, default) |
2 + (n - 1) * 2 + (n - 1) * ErroInfo 이벤트 (HasErrorInfo=true) |
| RaiseEvent | 1 (오퍼레이션 응답 없음) (타겟: 구독자가 없는 관심 그룹) |
1 + n + n * 사용자정의 이벤트 (타겟: 모두/브로드캐스트) |
2 + 2 * n + n * ErroInfo 이벤트 (HasErrorInfo=true) + Auth 이벤트 (토큰 리프레시) |
| SetProperties | 2 Broadcast=false |
2 + n + n * PropertiesChanged 이벤트 (Broadcast=true, 기본) |
2 + 2 * n + n * ErrorInfo 이벤트 (HasErrorInfo=true) |
사용자가 사용한 트래픽을 어떻게 계산하나요?
이는 매우 복잡한 주제입니다. 먼저, 계산 값은 이론적으로 추정한 값일 뿐이며 실제와는 다를 수 있다는 것을 아셔야 합니다. Proof-of-Concept를 구축하고, 이를 사용하여 실 데이터를 수집하는 것을 권장해드립니다.
여기서 언급한 것은 룸 안에서 한명의 사용자가 생성한 트래픽을 추정하는 방법입니다.
다음을 가정해보겠습니다:
- 룸안에는 N명의 플레이어가 있습니다.
- 한 명의 플레이어가 초당 F개의 메시지를 전송합니다 (메시지 전송률은 Hz)
- 평균 메시지 크기는 X 입니다(바이트 단위, 페이로드(payload, P) + 프로토콜 오버헤드(O))
- 평균적으로 플레이어는 한달동안 이 게임을 H시간 플레이합니다.
ACK, 연결 처리(설정, 활성 상태 유지 등)명령과 재전송을 고려하지 않았습니다. 그러면 게임은 평균적으로 다음과 같이 CCU는 게임의 C(바이트/월)를 사용합니다.
C = X * F * N * H * 60 (분) * 60 (초)
자체 호스팅
리눅스에서 Photon Server를 실행할 수 있나요?
아니오. Photon Server는 윈도우즈용입니다. 상세내용은 "요구사항" 을 읽어주십시오.
Amazon에서 Photon Server를 어떻게 호스팅하나요?
Amazon에서 Photon Server를 호스트하는 절차입니다:
- 새로운 윈도우즈 서버 EC2 인스턴스를 설정합니다
- Amazon Web Services 계정을 생성합니다.
- AWS 포털에 로그인 합니다.
- "Service -> EC2"로 이동합니다.
- "Create Instance" 섹션의 "Launch Instance"를 클릭합니다.
- Photon Server에서 지원하는 Microsoft Windows Server edition을 "선택" 버튼에서 클릭합니다.
- "Choose an Instance Type" 이후 "6. Configure Security Group"으로 이동합니다
- new security group "Photon Server" 생성하여 이 페이지에 나와있듯이 수신 포트를 허용합니다.
- "Review and Launch"를 클릭하고 검토 및 "실행"합니다.
- 키 페어를 기존 것을 선택하거나 생성합니다.
- 확인 토글을 선택하고 "Launch Instances"를 누릅니다.
- "View Instances"를 클릭하고 인스턴스가 초기화를 마칠때까지 대기합니다.
- 새로운 인스턴스에 RDP 연결
- EC2 인스턴스를 선택합니다.
- "Connect" 클릭합니다.
- "Get Password"를 클릭합니다.
- 개인키를 업로드하거나 내용을 복사하후 "Decrypt Password"를 합니다.
- "Download Remote Desktop File" 을 클릭하여 RDP 바로가기를 얻습니다.
- 바로가기를 더블 클릭하여 원격 머신에 연결합니다.
- 자격증명을 입력하여 로그인합니다.
- Photon Server SDK 설정
- Photon 계정을 생성합니다.
- Photon Server SDK를 다운로드합니다.
- 패키지를 풀고 원격 머신에 파일들을 복사합니다.
- Photon Control을 시작합니다.
- 서비스로 Photon을 설치합니다
- Photon 서비스를 시작합니다.
과금
학생, 취미자 또는 인디 개발자를 위한 특별 제안이 있나요?
저희의 모든 제품에는 프리티어와 일회 지불하는 가격 정책이 있습니다. 또한 우리는 Unity 에셋 스토어에서 판매를 하고 있으며 때로는 바우처를 제공해드립니다.
Photon 애플리케이션 하나에 대해 100 CCU 플랜을 하나 이상 결합할 수 있습니까?
아닙니다. 100 CCU 플랜은 겹쳐서 사용할 수 없으며 AppId당 딱 한 번만 적용할 수 있습니다. 여러개의 PUN+ 에셋 시트를 구입한 경우 AppId 별로 100 CCU에 대해 리딤해주어야 합니다. 단일 앱에 대해 CCU가 더 필요한 경우, 다음 단계의 플랜은 500 CCU 입니다. 월간 또는 연간 플랜에 가입한 경우 월/연간 플랜 CCU에 추가적으로 60개월 동안 100개의 CCU를 추가로 보관할 수 있습니다.