bdfgdfg

플랫버퍼의 사용은 스키마작성 -> flatc를 통한 컴파일 -> 헤더생성 -> 해당 헤더파일 추가 -> 가져다 쓰기(?).. 등의 단계를 거친다. 적어도 가져다 쓰기 이전의 단계는 이전에 만들어둔 스키마 작성단계만 한 후 자동으로 헤더생성까지 해주는 역할 + 해당 헤더파일도 자동으로 추가까지 구현해보았다. 이제 매번 스키마 파일마다 추가되는 헤더를 추가할 필요는 없고 저 PacketHeader 하나만을 추가하면 된다. 이제는 잘 가져다가 쓰는것도 중요. #include #include "files/GenPacket/PacketHeader.h" #include "KPacketHelper.h" int main( void ) { flatbuffers::FlatBufferBuilder builder; auto ..

직렬화 라이브러리를 뭘 사용할까 고민하다 플랫버퍼를 선택. 구글에 있는 간단한 예제만 보았는데.. 매번 txt파일 만들어서 fbs로 확장자 변경 후 도스로 flatc의 명령어를 날려주는게 번거로웠다. 그래서 플랫버퍼의 스키마 작성만 하고, 그 뒤의 번거로운 작업은 자동화 할 수 있게끔 처리해보았다. 스키마 파일과 작성한 스키마 파일들을 컴파일 해줄 flatc를 같은 디렉터리안에 넣어놓고. 직접 제작한 패킷 자동화 파일을 실행시키면 위와 같이 디렉터리가 생성되고.. 컴파일 된 결과만을 남긴다. 갈길이 멀다ㅠ

C++에도 있는거. 멀티쓰레드 환경에서 원자적으로 처리를 위해 사용한다. 내부적으로 다양한 것들이 있지만 중요하다 생각하는 것. Interlocked.CompareExchange 즉 비교와 교환을 원자적으로 처리한다. 밑의 코드가 있다고 생각해보자. void ExpireQuest() { if(Quest.bAlive == true) { Quest.bAlive = false; } } 어떤 퀘스트가 있고, 퀘스트 객체는 만료날짜를 넘어갔기에 해당 퀘스트를 닫아줘야 하는 코드. 만약 멀티쓰레드 환경에서 저 코드가 실행된다고 보자. A,B쓰레드가 있고 A와 B쓰레드는 저 Quest라는 객체에 동시에 접근하는 상황. A쓰레드는 if문의 Quest.bAlive가 true인것을 확인하고 해당 Quest의 멤버인 bAl..

웹,게임 서버 이 두 서버의 근본적인 차이는 웹의 경우 클라의 요청(REQ)이 있어야 응답(Response)이 있지만, 게임 서버의 경우 클라의 요청이 없더라도 자체적으로 연결된 액터들의 상태를 체크하며 변화가 발생될 경우 서버에서 직접 클라에게 어떠한 명령을 내릴 수 있다. - 이래서 웹 서버의 경우 Stateless, 게임 서버의 경우 Stateful 서버라고 한다. - 웹 서버라해서. 게임서버라해서 네트워크 계층(응용계층을 제외)레이어에서 다르게 동작한다는 것은 아님. 웹 서버는 보통 하나의 프레임 워크를 선택해서 개발하는 경우가 많기에 여기선 ASP.NET을 통해 공부를 할 예정.