Frequently Asked Questions

어떤 Photon 제품이 나에게 맞을까요?

이에 대한 답변은 주로 귀하의 프로젝트와 팀에 따라 달라집니다.
일반적으로, 저희는 가장 진보된 클라이언트 솔루션인 Fusion 또는 Quantum을 사용하는 것을 권장합니다.

빠른 개요를 위해 두 제품 시트 모두 제품 선택기 "Quadrant"를 포함합니다:

• Quadrant in Fusion slides
• Quadrant in Quantum slides

의문 사항이 있으시면 언제든지 연락주시길 바랍니다.

Photon Cloud

Photon Cloud는 다운되나요?

Photon Cloud 상태는 여기에서 확인하거나 트위터에서 @exitgames를 팔로우하여 상태 업데이트에 대해 알림을 받으십시오.

기본 Photon 지역은 어디인가요?

고객들은 최소 하나의 지역을 사용할 수 있으면 Photon Cloud에 연결할 수 있어야합니다.
이에 대해 보장을 위해, 기본값이 구성되어있거나 개발자가 명시적으로 값을 설정하지 않거나 "최적 지역" 옵션을 선택하지 않을 때 사용됩니다.
기본값은 클라이언트 SDK에 따라 다양할 수 있습니다.
원시 SDK에서는 OpGetRegions 에 의해 서버에서 리턴되는 지역 목록의 첫 번째 인덱스에 있는 값입니다.
Unity와 DotNet SDK에서 기본 지역은 "EU" 입니다.

일부 지역을 비활성화할 수 있나요?

예.
이 기능은 "비활성화된" 지역 없이 "지역 허용 목록"을 정의하여 작동합니다.
"대시보드 지역 필터링"에 대해 자세히 알아보세요.

모든 클라우드 서버/IP 목록을 얻을 수 있나요?

Photon Cloud가 너무 자주 변경되기 때문에 이러한 목록은 존재하지 않습니다. 서버가 추가되거나 제거되고 때때로 새로운 지역이 나타납니다. 즉, Photon Cloud(전체)를 허용 목록에 추가하는 것은 불가능합니다.

Enterprise Cloud의 경우 다른 주제이기 때문에 메일로 문의해 주시길 바랍니다.

Photon Industries Circle 내의 앱은 허용 목록에 대한 호스트 이름에 의존할 수 있습니다: *.photonindustries.io. 연결할 "서버"로 ns.photonindustries.io를 사용해야 합니다.

로드 밸런싱

Photon 룸이 지원하는 플레이어의 최대 수는 몇명인가요?

대부분의 Photon 멀티플레이어 게임은 2~16명의 플레이어를 수용하지만, 룸당 플레이어/피어의 이론적인 제한은 상당히 높을 수 있습니다.
32명 또는 64명의 플레이어가 참여하는 Photon 게임이 실시간으로 진행되고, 가상 회의 시나리오에서는 수백 명에 달할 수 있습니다.
그러나 초당 너무 많은 메시지(방당 메시지/초)를 보내면 데이터를 처리하는 클라이언트의 처리 능력에 따라 성능 문제가 발생할 수 있습니다.
턴제 게임과 같이 플레이어 수가 많은 것은 전혀 문제가 없지만, 빠르게 진행되는 액션 게임에서 플레이어가 32명이 넘으면 관심 관리를 구현해야 할 가능성이 높습니다.
이렇게 하면 모든 플레이어가 다른 플레이어로부터 모든 메시지를 받지 않게 됩니다.

게임 룸 내 데이터 트래픽을 증가시키는 주요 요인은 룸당 플레이어 수입니다.
따라서 객실당 메시지 수를 500개 이하로 유지하는 것이 좋습니다.
Photon은 이러한 제한을 강제하지 않지만, 공정 사용 정책을 따릅니다.
대역폭 사용량을 항상 살펴보는 것이 중요하며, 이를 통해 계획에 포함된 CCU당 3GB의 트래픽 범위를 벗어나지 않도록 할 수 있습니다.

Photon 문자열에는 제한이 있나요?

Photon은 룸 이름, 로비 이름, UserID, 별명, 사용자 지정 속성 키 등의 많은 목적으로 문자열을 사용합니다.

기술적으로, Photon 바이너리 프로토콜은 최대 32,767개의 1바이트 문자까지 문자열을 직렬화할 수 있지만 가능한 한 가장 짧은 문자열을 사용하는 것이 좋습니다.

이름과 사용자 ID의 경우 36자면 충분합니다(예: GUID는 36자입니다).
사용자 지정 속성 키의 경우 오버헤드를 최소화하기 위해 짧은 문자열을 사용해야 합니다.
특히 로비에 보이는 숙박 시설의 경우 이 사항이 중요한데, 이는 객실 목록의 일부로, 객실에 있는 몇몇 고객에게만 전송되는 것이 아니라 로비에 있는 모든 사람에게 전송되기 때문입니다.

사용자 지정 속성의 갯수에는 제한이 있나요?

네, 제한이 있습니다. 각 사용자는 13,000개의 키 값을 설정할 수 있으며, 룸의 총 크기는 500kB를 초과할 수 없습니다.
사용자 정의 속성이 많을수록 클라이언트가 모든 속성을 받게 되므로 클라이언트가 방에 참여하는 데 걸리는 시간이 길어집니다.

Photon을 사용하여 매우 큰 메시지를 보낼 수 있나요?

무엇을 해야 할지 잘 모르는 경우 Photon을 사용하여 대용량 데이터(예: 파일)를 전송하지 않는 것이 좋습니다.
여러분이 교환하는 데이터를 최적화하고, 정말로 큰 메시지를 보내야 하는 경우 저희에게 연락하는 것이 좋습니다.

Photon Cloud에는 클라이언트 버퍼에 대한 서버 측 제한이 있으며, 이는 500KB입니다.
따라서 맥락에 따라 메시지는 다음과 같이 고려될 수 있습니다.

• Photon Cloud의 클라이언트당 버퍼 크기가 500KB를 초과하면 "너무 큽니다". 클라이언트가 짧은 시간 내에 이 한계에 도달하면 서버에서 연결이 끊어집니다.
• UDP로 전송하기에는 "너무 커서" 100KB가 넘는 조각으로 인해 문제가 발생할 수 있습니다.
• 여러 개의 UDP 패킷으로 분할하지 않고는 전송하기에는 "너무 큽니다" > 1.2KB(프로토콜 오버헤드 포함).

매우 정기적으로(1초에 10회 이상) 전송되는 메시지의 경우 크기를 1KB 미만으로 유지하는 것이 좋습니다.

메시지가 거의 전송되지 않는 경우(예: 경기 시작 시 한 번 전송)에는 여러 KB 크기가 괜찮지만, 여전히 10KB 미만으로 유지하는 것이 좋습니다.

더 큰 메시지는 별도의 Enet 채널(UDP)로 전송할 수 있으며, 이렇게 하면 다른 채널(상태 동기화)에 미치는 영향이 줄어듭니다.

대용량 파일의 경우 별도의 백엔드를 사용하는 것을 고려하세요.

어떤 데이터가 신뢰성있게 전송되며 신뢰성 없게 전송되는 데이터는 어떤것입니까?

무엇보다도, 프로토콜이 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 서버에서 살아남을 수 있습니다.
  플레이어가 마지막으로 나가고 방이 비어 있으면 EmptyRoomTTL은 플레이어가 참여하거나 다시 참여하기를 기다리면서 방이 살아 있는 시간입니다.
  EmptyRoomTTL 이후에도 룸이 비어 있고 아무도 참여하지 않으면 해당 룸은 Photon 서버에서 제거됩니다.
  지속성 조건이 충족되고 웹훅이 설정된 경우, 룸 상태를 구성된 웹 서비스에 저장하여 나중에 로드할 수 있습니다.
• 액터가 비활성으로 표시됨: 동일한 UserId를 가진 액터가 액터 목록 내에 있지만 현재 룸에 참여하지 않은 경우입니다.
  이렇게 하려면 PlayerTTL이 0이 아니어야 합니다.
• 비활성 액터의 PlayerTTL이 만료되지 않았습니다. 액터가 돌아올 수 있는 옵션과 함께 방을 나갈 때 비활성화 타임스탬프를 저장합니다.
  방이 활성화되어 있는 한, 비활성화 시간 후에 PlayerTTL 밀리초가 경과하면 해당 액터는 액터 목록에서 제거됩니다.
  그렇지 않은 경우, 액터가 재참여를 시도할 때 재참여 시도 시간과 비활성화 시간 사이의 밀리초 차이가 PlayerTTL을 초과하면 액터는 액터 목록에서 제거되고 재참여는 실패합니다.
  따라서 비활성적인 행위자는 비활성화 시간 후 PlayerTTL 밀리초 동안만 룸에 다시 참여할 수 있습니다.

A "빠른 재입장"은 두 단계로 구성됩니다.

• Reconnect: 연결이 끊어지면 적절한 연결 방법을 호출하기만 하면 됩니다.
• Rejoin: loadBalancingClient.OpRejoin(roomName)을 호출합니다.

과금

학생, 취미자 또는 인디 개발자를 위한 특별 제안이 있나요?

저희의 모든 제품에는 프리티어와 일회 지불하는 가격 정책이 있습니다.
또한 우리는 Unity 에셋 스토어에서 판매를 하고 있으며 때로는 바우처를 제공해드립니다.

Photon 애플리케이션 하나에 대해 100 CCU 플랜을 하나 이상 결합할 수 있습니까?

아니오.
100 CCU 플랜은 겹쳐서 사용할 수 없으며 AppId당 딱 한 번만 적용할 수 있습니다.
여러개의 PUN+ 에셋 시트를 구입한 경우 AppId 별로 100 CCU에 대해 리딤해주어야 합니다.
단일 앱에 대해 더 많은 CCU가 필요한 경우, 다음으로 높은 요금제는 500 CCU입니다.
월간 또는 연간 플랜에 가입한 경우, 월간/연간 플랜의 CCU에 추가로 12개월 동안 100 CCU가 유지됩니다.

Photon 플랜에 얼마나 많은 트래픽이 포함되어 있나요? 앱에서 포함된 한도를 넘는 트래픽을 생성하면 어떻게 되나요?

Photon Public Cloud 및 Premium Cloud 플랜에는 CCU당 3GB가 포함됩니다.

예를 들어, 1,000개의 CCU를 갖춘 월간 요금제에는 월 3TB의 트래픽이 포함됩니다.

앱이 더 많은 트래픽을 생성하면 자동으로 이메일을 통해 알림을 보냅니다. 매월 말에 Photon 계정 이메일 주소로 자동 생성된 초과 청구서를 받게 됩니다. 청구서 금액은 다음 계산을 기반으로 합니다.

총 트래픽 - 포함 트래픽 = 초과 트래픽(GB)

트래픽은 사용된 Photon Cloud 지역에 따라 GB당 90원/180원으로 계산되고 추가 청구됩니다.

Photon Cloud 플랜의 구독한 CCU를 피크 CCU가 초과하면 어떻게 되나요?

500 CCU / 1,000 CCU / 2,000 CCU 플랜에 가입한 경우, 애플리케이션에 대해 "CCU 버스트"가 자동으로 활성화됩니다. Photon Cloud는 사용자에게 최상의 경험을 제공하기 위해 예약한 것보다 더 많은 CCU를 허용합니다.

버스트가 시작되면 합의된 조건에 따라 48시간 이내에 필요한 구독 등급으로 업그레이드해야 합니다.

업그레이드하지 않으면 Photon 계정 이메일 주소로 "초과 청구서"를 보내고 구독한 플랜을 초과하는 각 CCU에 대해 CCU당 1350원/1400원/1800원(사용된 SDK 기준)의 수수료를 청구합니다.

Photon은 "피크 CCU"는 해당 달에 합산된 지역별 피크 CCU의 합계입니다. 피크에 도달한 후 사용량이 감소하더라도 초과 요금을 피하기 위해 업그레이드해야 합니다.

Back to top