Interface - Protocol 상속 interface abstact 차이? PacketHandler 해당 패킷이 다 조립이 되었으면 무엇을 호출할지 도와주는 역할 PacketManager

✅ 지난 시간 PacketId가 담긴 Enum을 포함하여 FileFormat을 새로 추가해주고, byte와 이중list 상황에서 테스트 해보며 대응코드를 작성해주며 자동화를 더 개선하였다. PDL 문서 자동화 지난 시간 PDL 생성하여 복사한 뒤에 Debug 폴더에

PacketFormat이라는 Class를 통해 패킷 처리 코드를 자동화하는 작업을 하고, 완성된 코드를 기존 코드에 대체해보며 잘 동작하는지 테스트해보았다. 오늘도 이어서 이 자동화 코드를 개선해볼 것이다.계속 코드를 수정하면 Client, Server를 왔다갔다 하며

간단하게 패킷 자동화를 어떻게 할 수 있을지에 대한 개념이해를 위해 큰 틀을 짜놓는 작업을 하였다. xml파일에 담긴 데이터를 읽어와 각 타입에 맞게 변화시키는 작업이 귀찮지만 굉장히 유용해서 추후 다른 프로젝트에서도 종종 사용할 수 있을 것 같다.기존에 using문을

지난시간 Packet Generator 자동화는 하드코딩으로 진행하여 구성한 뒤 자동화할 수 있는 부분으로 돌릴 수 있다. XML 추가 XML 읽어오기 기존에 하드코딩 내역 복사하여 고정영역과 변동영역을 구분하기 ![](https://velog.velcdn.c

지난 시간 int, short 같은 사이즈 크기가 정해져있는 것과 다르게 string 타입은 입력 값에 따라 변하기에 다른 방법으로 처리를 해주어여했다. 하지만 새로운 방법이 아닌 기존 처럼 string을 얼마나 사용할 건지 미리 넘겨주고, 그 만큼 메모리에 할당하는

long은 8바이트, short은 2바이트 이렇게 크기가 정해져있지만 string 타입의 경우는 정해져있지 않기에 넘기기 어렵다. array write slice로 변경 read도 slice로 변경 string을 어떻게 넘길지 고민 c#에서는 string, cha

지난시간

보통 관심분야가 있을 때 책을 통해 다른 사람들의 마인드셋이나 지식들을 많이 배우곤 하는데, 아직 개발에 대한 지식이 부족하기에 깊이가 깊은 책은 어려워 쉽게 읽을 수 있는 책을 찾다가 알게 되었다.'쌀 팔다 개발자'라는 타이틀로 쌀을 팔다가 나와 비슷한 나이로 개발자

serialization, deserialization. 직렬화와 역직렬화 작업을 간단하게 실험해보며 현재 부족한 부분의 코드를 개선하는 작업을 하였다.지난시간에 열심히 개선해준 OnConnected에서 buffer를 날려준 부분을 더 사용하기 편하게 PlayerInf

간략하게 Send 처리를 하던 부분을 조금 더 효율적으로 개선하는 작업을 배웠다. 오늘도 이어서 더 개선할 수 있는 부분을 찾아 개선할 것이다.string이나 list 같은 타입이 추가 될 경우 단순하게 숫자 넘겨주는 방식으로는 진행이 어려워 압축하여 보내는개념 Cla

Open()을 통해 큰 사이즈를 만들고 사용한 만큼 Close()에 넣어 할당하며, 큰 사이즈의 크기에서 점점 채워가며 사용하는 방식의 SendBuffer를 제작하였고 이제 본격적으로 패킷 작업을 위해 구성을 해놓을 것이다. 패킷의 값으로 구분하기패킷을 전송하는 방식을

Receive Buffer를 제작하여 하드 코딩식이 아닌, 패킷 처리가 됐을 때도 적용 가능하도록 틀을 구성하였다. 기존 Send는 Encoding 하여 byte타입으로 넘겨주고, SendQueue에 저장하며 처리하는 방식이었다. 이번에는 이 부분을 개선 해줄 것이다.

TCP와 UDP가 뭔지 조금 더 자세하게 알아보고, 이번 프로젝트를 제작해보며 사용하게 될 TCP에 특성에 대해 알아봤다.TCP의 특성중 현재 처리 가능한 패킷만 받고, 나머지는 나중에 처리하는 것이 있는데 이럴때 상황을 처리하기 위해 코드 작업을 해놓아야 한다.시작시

TCP/IP 프로토콜 을 학습할 당시에 간단하게 알고 넘어갔지만 패킷 통신처리를 하기 위해서는 TCP는 뭐고, UDP랑은 어떤 차이가 있는지 이해해야 처리를 할 수가 있다.TCP로 구성시에는 요청시에 100bytes를 요청해도 상황에따라 30bytes 만 처리하고, 나

클라이언트와 서버간의 통신은 당연하지만, 서버만 있는 곳에 왜 Connector가 필요할 까 의문이 들 수 있다.이유는 게임 서버를 구축하다 보면 서버가 여러개 제작 되기도 하는데, 이때도 서버끼리도 한 명은 요청을 보내고 받는 구조이다. 결국 서버 끼리도 연결 요청이

버퍼를 하나씩 보내는게 아닌, BufferList를 활용하여 버퍼들을 한 번에 담아 보내는 방법으로 수정을 하고, 그 과정 중에서 배열의 일부분을 받을 수 있는 ArraySegment< T >를 배워 적용하였다.Send를 할 때는 지난 번 구현한 것에서 처리를 하

Accept, Receive의 비동기 처리까지 완료하고, send를 비동기 처리하는 작업을 하였다. 하지만 아직 효율적이게 개선이 완료된 것이 아니기에 오늘도 이어서 개선해나아갈 예정이다.\_sendArgs는 버퍼 사이즈 설정 이슈로 receive 처럼 새로 생성하고

Receive 하는 부분을 새로운 Session Class로 구분하여 코드를 정리하고, listener 처리와 동일하게 SocketAsyncEventArgs를 사용해 비동기 처리를 제작하였다. 오늘은 이어서 Send 부분을 처리할 것이다.지난 시간 Receive는 사용

코드를 조금 더 효율적이게 구분하고, 비동기 처리가 될 수 있게 구현을 해보았다. 과정중에서 이벤트 기안을 동작하는 SocketAsyncEventArgs 를 사용하여 아주 편하게 코드 구성을 할 수 있었다.유저들이 많이 몰릴 경우 처리 \-> 해당 부분을 여러개 생성하