We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
이전에 올렸던 구조를 쓰레드 기준으로 아니라 프로그램 기준으로 생각해서 조금 다른 관점에서 접근을 해보았습니다.
통신 레이어 / 필드 레이어 / 기타 레이어 / 조작레이어 3개의 구성이며 통신레이어만 서버로, 필드랑 기타는 클라이언트 방식으로 제작할 생각입니다.
이런식으로 필드 / 기타 레이어를 클라이언트 방식으로 처리해서 서로 통신하게 하는게 올바른 방법인가 싶습니다.
본래라면
일텐데 저 방식이라면
이런식으로 몇가지 과정이 추가되므로, 이 과정의 딜레이가 어느정도 발생하지 않을까 라는 고민이 듭니다. 그밖에도 이렇게 구성하는게 올바른건지도 잘 모르겠네요 ㅠㅠ..
이렇게 구성 해도 별다른 문제가 일어나지 않으려나요?
CGSF에 관련된 질문은 아닌것 같지만
카페쪽에서 질문은 불가능하여 여쭈어봅니다 ㅠㅠ
The text was updated successfully, but these errors were encountered:
카페 등업해드렸으니 일단 mmo 관련 글을 찾아 보시고 그래도 답이 안나오시면 질문주세요 ^^
Sorry, something went wrong.
No branches or pull requests
이전에 올렸던 구조를 쓰레드 기준으로 아니라 프로그램 기준으로 생각해서
조금 다른 관점에서 접근을 해보았습니다.
통신 레이어 / 필드 레이어 / 기타 레이어 / 조작레이어 3개의 구성이며
통신레이어만 서버로, 필드랑 기타는 클라이언트 방식으로 제작할 생각입니다.
곧바로 유저를 받지는 않고 필드, 기타 레이어 클라이언트가 들어오기를 대기합니다.
이 각 기능을 담당하는 클라이언트의 개수는 통신레이어측에 직접 지정해줍니다.
그 개수가 전부 할당 될 때까지 기타 유저의 통신은 받지 않습니다.
혹시 모를 해킹에 대비해서 레이어별 암호를 설정하여 그 암호로 순번을 식별
각 레이어에서 하도록 한다.
이런식으로 필드 / 기타 레이어를 클라이언트 방식으로 처리해서
서로 통신하게 하는게 올바른 방법인가 싶습니다.
본래라면
다른 플레이어어들에게도 이 플레이어가 이동명령을 시작했음을 알린다.
일텐데 저 방식이라면
다른 플레이어어들에게도 이 플레이어가 이동명령을 시작했음을 전달하는 패킷을 통신에 보낸다.
이런식으로 몇가지 과정이 추가되므로, 이 과정의 딜레이가 어느정도 발생하지 않을까
라는 고민이 듭니다. 그밖에도 이렇게 구성하는게 올바른건지도 잘 모르겠네요 ㅠㅠ..
이렇게 구성 해도 별다른 문제가 일어나지 않으려나요?
CGSF에 관련된 질문은 아닌것 같지만
카페쪽에서 질문은 불가능하여 여쭈어봅니다 ㅠㅠ
The text was updated successfully, but these errors were encountered: