대충 현재 환경은 고정 공인IP, 속도는 대충 고정적으로 10Mbps 정도 되는거같고
테스트인원은 10~15명 내외, 서버-_- 사양은 펜 1.5G/ 램 768M, win2003입니다. 아직 DB는 사용하지 않고 있구요.

게임 특성상 서버가 왠만하면 먼저 스스로 데이터를 보내지 않고, 데이터가 들어와야만 응답을 보내는 것에 가깝습니다.
(그렇지만 당연히 메시지 큐 프로시저는 쓰레드로 돌아갑니다; )
현재는 TCP의 무결성을 믿고-_- 한번 보낸 데이터는 잘 갔는지 말았는지 확인도 안하구요.
만약 TCP를 아주 믿지는 못한다면 상태 종종 체크해가며 명령 재전송도 해줘야 할거같습니다.

그게... TCP/IP 의 경우에는, 일단 데이터 무결성이라고 믿어야 합니다. 안그러면 스트리밍 방식으로 짤 수가 없습니다;;;

다만, 100바이트를 Send 했을때 저쪽에서 30바이트만 받고, 70바이트는 나중에 받는 경우는 있습니다.
무슨 방식을 사용하시는지는 잘 모르겠지만, 예를 들어 FD_READ 메시지가 발생했을 때,
recv( buf, 100 ); 했다고 해서 100 바이트를 다 받아오는건 아니라는 말입니다.
즉, 원하는 바이트만큼 다 받을때까지 recv를 호출해야 합니다. 이건 send 에도 마찬가지구요.

음 그럼 결국 제가 =_= 잘못짠거네요;;

TCP니까 일단 스트리밍이고, 넌블러킹 모드는 IOCP로 만들었습니다.
IOCP니까... recv로 하는건 아니고, 버퍼에 쌓이는 데이터의 각 패킷 전면부에 헤더를 둬서 그 헤더에 적힌 만큼의 데이터가 차올랐을때만 한 패킷으로 인정하고 데이터 처리 큐에 쌓아주는걸로 되어있습니다.
보내는 입장에서도 한번에 다 못보내면 다 보낼때까지 여러번 보내도록 되어있습니다. 센드명령은 한 대상에 관해 중첩으로 내려질 수 없게 되어있구요.

버퍼 관리는 일단 원형 큐 방식으로 되어있구요, 전에 큐를 짤 때 후면부에서 전면부로 회귀할때 루틴을 잘못 짜서 오류가 나는 부분이 있었는데 그건 잡았구요... 적어도 랙이 없는 상태(랜 망) 버퍼 회전에서는 별 문제가 없었습니다. 근데 이번에 나는 오류는 회전상 문제도 아니고 위치 안따지고 걍 마음대로 문제가 생기네요. 뭔가 분명히 문제가 있긴 할텐데...

아 그리고 덤으로 질문입니다만
DB와 Visual C++ 간의 연동 방법에는 어떤것들이 있는지 알고싶습니다.
ODBC로 하는거 외에도 다른 방법이 있는지, 혹시 CRecordSet 외의 다른 방법들이 있는지...
그리고 CRecordSet은 MFC 베이스로 해야된다고 본거같은데 걍 어떻게 쉽게 쓰는방법 있는지 등등;;
(제가 api하고 mfc쪽에 공부량이 부족해서;; 근데 찾아봐도 php연동이나 VB연동 같은건 많아도 VC용은 자세한게 찾기 어렵네요; )

아.. IOCP로 하셨다면, 예외상황이 무지 많이 생깁니다;;;
일단은 TCP/IP Layer에는 문제가 없다고 가정하고, 차근차근 디버그해보시는거 밖에는 방법이 없을 것 같네요..

그리고, DB쪽은 ado를 찾아보세요. COM 이라서 좀 사용하기가 짜증스러운 면이 없지 않아 있지만...
속도면이나 편리함에 있어서는 최고 같네요. 데브피아 같은데 뒤져보시면 강좌도 있을거구요.
ado를 그냥 막 쓰려고 하면 상당히 어렵지만, VC에서 마법사를 지원하니까, 그거 관련해서도 잘 찾아보시구요.

으 네트웍은 역시 문제상황 재현이 어려워서 -ㅂ-; 으으 디버그 어떻게 해야할지;;
근데 ADO는 책을 한권 사볼까 했더니 책이 줄줄이 절판절판절판품절품절절판품절...;;

아.. ADO.. 정확하게는 OLEDB 군요.. OLEDB 관련 책들.. 제법 있을텐데요?
그리고, 단순 Select/Insert 정도라면 책 까지도 필요없더군요. MSDN과, 인터넷에 돌아다니는 강좌로도 충분!

감사합니다^^
제가 가는 곳이 좀 좁은편(기껏해야 뎁피아 C++페이지 정도;; )이라 잘 못찾는듯한데 일단 더 찾아보겠습니다 -ㅁ-)/

DB 뭘 쓰는지 잘 모르겠지만 저도 이방법때문에 참 고민 많이했습니다. 레코드셋 안쓰고 쉽게 접근하는 방법이 없을까해서요
저는 MySQL ODBC 설치하고 그거 관리도구에서 추가해주어서 사용했습니다.
기본적인 예를 들자면

_ConnectionPtr pConnection;
_RecordsetPtr pRecordset;
컨넥션 포인터랑 레코트셋 포인터를 이용해서

_bstr_t strCnn("Provider=MSDASQL.1;Password=******;Persist Security Info=True;User ID=root;Data Source=bis;");
pConnection->Open(strCnn, L"", L"", -1);

//컨넥션 스트링 strCnn 을 만들고 DB를 오픈합니다.

query.Format("여기는 쿼리가 들어감'", 변수); //쿼리작성하시고
pRecordset = pConnection->Execute((_bstr_t)query, NULL, adOptionUnspecified); // 쿼리 실행 구문

//그리고 레코드를 가져오는것이죠 기본적으로 while 문 쓰죠 (대충 아시리라 생각하고)

while (!pRecordset->GetEndOfFile())
{
vData = pRecordset->GetCollect(L"busnum"); // 여기서 busnum -> 이건 필드명입니다.
busnum[cnt] = (LPCTSTR)(_bstr_t)vData; // vData 는 _variant_t형의 변수입니다. _variant_t 자료형은 MSDN 참조
pRecordset->MoveNext(); // 이거는 당근 다음 레코드
cnt++; //이거는 레코드 겟수 카운트용 변수 필요하시면 써도 되고 안써두 됨
}

// 대충 이렇게 하면 간단합니다. 전체적으로 설명하자면
// init 에서 디비를 오픈해주고 (컨넥션 스트링 사용)
// 쿼리 작성해서 쿼리 실행
// 레코드가 마지막일때까지 한 레코드씩 가져오기
//자세한건 메일을~

그 문제는 당연히 일어나죠!
Local Network에서는 문제가 되지 않는데, 이상하게 Internet backbone에 붙으면 날리를 칩니다.
당연하겠죠. 우리는 네트워크 프로그래밍을 하면서 TCP/IP의 신뢰성만 믿고 보내면 족족 그대로 받는다고 알고 있지만
사실은 꼭 그렇지 많은 않습니다. 왜냐하면 Fragmentation이라는 원리 때문에 그런데요.
인터넷을 구성하는 네트워크의 특성은 다양합니다. 네트워크의 패킷의 Size가 제한되어 있는데, 이것을 MTU(Maximum Transfer Unit)이라고
합니다. 한쪽에서 아무리 2KB를 보냈다 하더라도, 어떤 네트워크에서는 1500B와 500B(약) 으로 2개로 쪼개져 들어오는 경우도 있구요.
576B정도로 쪼개져 들어오는 경우도 있습니다.

이럴 때 어떻게 하면 되느냐! 네트워크 공부를 하셨다면 아시겠지만, MTU에 대한 접근은 프로토콜 설계시 Header라는 녀석에 달려 있습니다.
최소한 Header는 받는다고 가정하고, Header를 받은다음에 Payload의 Size를 읽어서 해당 Size가 들어올 때까지 반복해서 받습니다.
물론 여기에도 여러 장치들이 필요하겠죠! 만약 물리적으로 네트워크 선이 끊어진다던지, 네트웍이 불안정해서 도저히 서비스를
할 수 없을 때에 대한 대비등이 들어가야 합니다. 다음은 제가 예전에 만든 코드인데, 참고하세요. 다음 순서대로 진행하면 됩니다.

1. Header를 먼저 받아 Payload Size를 읽어낸다.
2. Payload Size로 다시 호출하여 버퍼에 꽉찰 때 까지 받는다.

sockfd는 연결된 소켓
이래코드에서 buff는 충분히 크게 잡으시고, nBuffSize는 버퍼 크기
nLength는 네트워크 recv버퍼에서 받을 양(Header1번 호출, Payload 1번 호출)
tvBlockTime은 해당 시간(interval)안에 데이터가 수신이 되지 않았을 경우 에러 반환시간
입니다.
함수의 결과 에러는 SOCKET_ERROR이 반환됩니다.
스트레스 test까지 거친 작품으로 인터넷 기반에서 잘 동작하게 설계되었습니다.
Send쪽은 신경안써도 알아서 보내지지만, recv는 그대로 사용하면 안되고 꼭 아래 코드를 참고해서 하세요.
MTU로 인한 문제를 효율적으로 개선시켜 줍니다. 그리고 header는 너무 크게 만들면 안되겠죠.
또한 header에 괜히 payload까지 붙혀서 recv하지 마시고, 염두! header한번 header에 적히 payload사이즈만큼
1번 더! 당연히 send할 때 header에 payload만큼 적어주는정도의 센스!

int ITCPSocketServer::RecvLine(SOCKET &sockfd, char *buff, const int nBuffSize, const int nLength, const timeval tvBlockTime)
{
int nRetval;
timeval tv;
int nRecvSize = 0;

fd_set fdSet, fdMaster;
FD_ZERO(&fdMaster);
FD_SET(sockfd, &fdMaster);

if(nLength == 0)
return 0;

if(nBuffSize < nLength) // pre-condition
return SOCKET_ERROR;

while(nRecvSize < nLength)
{
tv = tvBlockTime;
fdSet = fdMaster;
nRetval = select( sockfd + 1, &fdSet, NULL, NULL, &tv);
if(nRetval == 0 || nRetval == SOCKET_ERROR)
{ // timeout
break;
}

if(FD_ISSET(sockfd, &fdSet))
{

nRetval = recv(sockfd, (buff + nRecvSize), (nLength - nRecvSize), 0);
if(nRetval == SOCKET_ERROR || nRetval == 0)
break;
else
{
nRecvSize += nRetval;
}
}

if(nRecvSize == nLength)
return nRecvSize;
else if(nRecvSize > nLength)
{
fprintf(stderr, "crt: RecvLine() call failed - Occur an overflow [RecvSize:%d][nLength:%d]",
nRecvSize,
nLength);
break;
}
printf("loop [Received Size : %d]n", nRecvSize);
}

return SOCKET_ERROR;
}