Page History

bool SomeOptionA;

bool SomeOptionB;

int SomeNumOption = 3; //range 1-100000

10년전 네트워크 환경을 고려하면 위와같은 패킷 정의는 바람직 하지 않았습니다.

작은 단위의 데이터를 사용하는것은 DB뿐아니라 네트워크 전송환경에서도 고려되는 사항입니다고려해야하는 사항으로.

위 구조체는 6byte를 차지하며, 아래와 같이 3byte로 줄이는게 가능합니다.

컴파일러 최적 에따라 4바이트 경계사용시 실제는 8 / 4바이트가 됩니다.

이것을 줄이기위해 pragma pack이라는 다소 부자연스러운 키워드도 사용하게 됩니다.

unsigned char SomeOptions; //OR연산 비트플래그 처리로 작은 데이터에 다중옵션가능합니다.

unsigned short SomeNumOption; //음수영역을 제거함으로, 기존 사용하던 데이터범위보다 한단계 작은 단위 사용가능

하지만 네트워크 성능이 충분히 좋은 요즘은, 의미해석 관점에서 이러한 설계가 오히려 바람직하지 않는 케이스가 되었습니다.

비트 연산한 값을 DB에 저장해버리면, 어떠한 의미에서는 매직넘버가 될수가 있습니다.

또한 최소의 값을 사용하여 확장발생시 새로운 필드를 추가해야 하는케이스보다 적절하게 너무크기않은 충분한 값을 사용하여 데이터 범위 확장에 대비하는것이

훨씬더 이득이기 때문입니다. ( 웹확장성및 이기종 통신을 고려하여 요즘은 json(serializer) 선택의 문제로 축소가됨 )

위와같은 개발경험으로 처음 웹서비스를 서버를 통해 제공하는 코드를 작성 했을시 HttpRequest가 500byte이상의 헤더값이 항상 존재하는것과

500byte면 1분정도의 게임 한사이클을 처리할수 있는 사이즈이며, Http 전송횟수제한과 더불어 네트워크 성능 튜닝을 위한 걸림돌이였습니다.