TCP/IP와 UDP/IP를 이용하여 소켓프로그래밍을 하고 있습니다.
server와 client를 만드는 것까지는 성공하였습니다.
특히 recv를 사용할 때에는 thread를 이용하여 프로그래밍을 했구요.
여기 고수님들의 조언이 만들수 있는 원동력이었습니다.
그리고.. 염치불구하고 또 물어봅니다.
recv함수는 서버가 데이타를 안주면 무한정 delay가 걸리더군요.
그래서 thread로 해결을 했습니다.
그런데 send함수도 delay가 있습니까?
겉으로 보기에는 delay가 없는 것처럼 보이던데...
혹시 아시는 분 계신가요?
그리고 이곳 게시판을 계속 보고 있는데, nonblocking모드를 사용하는게 좋다고
하더군요.
음... 전 socket, listen, accept와 connect함수를 이용하여 연결한 후에
send와 recv함수로 통신을 하는데... 어느 부분에서 nonblocking모드와 blocking
모드를 셋팅해 주어야 하나요? 
도움 주셨으면 감사하겠습니다.
으으~ 고수의 그날까지...
그럼 고맙습니다. 
우선 소켓의 상태에 따라 각 함수들이 delay가 될 수도
블러킹이 걸릴 수도 있습니다.
blocking mode, nonblocking mode, asynchronous mode3가지
가 있는데 그중 어떤 것을 썼느냐에 따라 달라 지겠죠.
보통 프로그램의 종류에 따라 유리한 조건의 소켓이 있겠지요.
제 경험으로는 asynchronous mode가 가장 좋았던 것 같습니다.
여러 클라이언트를 처리하는 서버에서는 특히나..
왜냐면, 한 클라이언트한테 서버가 잡혀 있으면 안되니깐요.
connect같은 경우는 어차피 이 함수가 수행이 되어야 다른 일들을
할 수 있을 테니 블러킹이 되도 상관 없을 것 같네요(연결 안되는 경우를
대비해서 30초 이상 블러킹이 되는 건 막아야 겠죠? 아니면 컴퓨터 재부팅
해야 하니깐)대충 기억을 더듬으며 말 씀 드렸는데, 도움이 됐나 모르겠네요
그럼 이만.... 
tcp에서 send가 성공적으로 완료되었다는 말은 내부적으로
수신측과의 패킷교환이 완전히 끝났다는거겠죠.
수신측으로부터 성공적으로 받았다는 메시지를 받기 전까진
send가 완료된게 아니죠.
따라서 블럭킹 모드에선 send도 딜레이 될수 있습니다.(라고 생각.
언제나 lan환경에서만 테스트 해봐서 딜레이 되는건 보질 못했지만)

로긴할때는 스레드를 써도 상관없겠지만 send와 recv를 할때는 비동
기 모드를 사용하는게 좋다는 생각입니다.클라이언트는 그래도 문제가
덜한데 서버에서 모든 컨넥션에 대해 recv,send를 스레드로 돌린다면
그 부하가 엄청나겠죠. 
영천님이 잘못 알고계신듯 하네요.
send는 수신측과 관계없이 네트웍상에 패킷을 뿌리는것만으로 완료됩니다.
수신측이 메세지를 모두 받지 못해도 send함수는 리턴되죠.

블러킹모드에서 send가 딜레이 되는 상황이 있긴 하지만
수신측의 수신여부와는 관계가 없습니다.

인터넷 상에서 테스트해보시면 될겁니다.

경험한바로는 대게 send의 블러킹은 대량의 데이터를 짧은 시간에 
날릴때 일어나곤 하더군요.
소켓레이어의 버퍼가 가득차서 그런게 아닐까.. 생각합니다만, 정확한건
모르겠네요.

그리구.. 소켓 쓰시려면 non-blocking 보다는 blocking 쓰시길 권합니다.
non-blocking 소켓을 쓰면 send시의 에러처리를 보아야 하는데..
이게 WOULDBLOCK 일경우 send는 실패한게 됩니다. (winsock의 경우)
여기에 따른 처리가.. 말도안되게 복잡(blocking에 비해서)하죠.
스레드를 쓰던가, I/O Multiplexing을 쓰던가 해서 blocking소켓을 쓰는게
나중에 디버깅하기도 쉽구요..

- Testors

ps. e로 추가합니다.
제가 보기엔 TCP 에서 send 하면 해당 프레임의 패킷을 받았다는 ACK가 
돌아와야 하는데 이게 오지 않을경우.. 물론 이경우 send는 블럭되지
않습니다. 이렇게 되면 데이터는 천상 send한측의 버퍼에 쌓이게 되는데요
이때 쌓이다가 계속적인 send요청으로 버퍼가 가득차게 되면 그후 send에서
블럭되는듯 합니다. 
send delay는 블러킹인 경우 system buffer가 꽉찬경우에
더이상 쓸수 없음으로 빌때까지 기다릴때 일어 나는 것이고
nonblocking 혹은 asynchronous mode인 경우에는 절대로
delay가 일어나지 않고, 단지 보내기에 성공한 byte수만큼만
return하게 됩니다.
따라서, nonblocking과 asynchronous mode인 경우에 완전하게
send를 완료 하기 위해서는 그 return된 값을 항상 확인하여
다시 그 다음 byte부터 send하여야 합니다.
이 부분이 좀 복잡하죠..
혹시 잘못된 부분이 있다면 고수님들의 조언 부탁 드립니다.
제가 책에서 봤던 내용 이니깐 맞을 꺼에요. 기억을 더듬어
쓴 것이지만요...
그럼 이만.....

jadoo 
API소켓에서, bind부분에서 자꾸만 1038번에러(WSAENOTSOCK)가 나네요..

해결책좀..

대강 어떤말인지는 알겟는데..

해당 애플리케이션에 대해 지정된 소켓 기술자가 유효하지 않음,

이라는 말인데, 뜻을 모르겟네요.
해결책을

그럼
. 
요즘 책좀 읽고 있는데요.
RS-232-c라는 내용이 많이나오는군요.
처음에는 프린트포트를 말하나..
아니..야..마우스포트인가??
음...그것도아니고 흠.
확장슬롯인가.
훌.
지금은 거의 안쓰고 있는.
핀9개짜리 프린트포트근처에있는 포트로
생각하고 있는데.
훌.자세히 아시는분 답변좀.
그럼. 
먼저.. 소켓 에러는....
제 생각에 소켓 디스크립터로 만약 m_Sock을 선언했다면.
bind전에 반드시 소켓 생성을 해 줘야 합니다.
m_Sock은 말 그대로 소켓 디스크립터를 저장할 변수일 따름이죠.
디스크립터 생성은 뭐, WSASocket()을 쓰던가..
socket()을 쓰던가..(맞나?) 하심 됩니다.
그 다음에 bind()하심 되겠죠.

그런데, 이 걸 안 하셨을리가... ㅜ.ㅜ
다른 부분도 확인해 보시길..
근데, 그 에러는 이거 밖에 없는 거 같은데. 쩝..

두번재로, RS-232C는 시리얼 포트에 대한 표준 규약입니다.
뭐 이거에 대한 내용이 많이 중요하지는 않으리라고 생각됩니다.
요즘 시리얼 포트의 중요성이 떨어지는 추세라.. 
USB로 많이 옮겨져 가니까여..

그럼.
시리얼 프로토콜 규약이라..
이건 이해하겠는데.
구체적으로 무엇들을 말하는지요.
그러니까.
본체뒤에 뭘말하는건지요.
^^
물리적인 부분을 설명좀 해주세요..
죄송.
그럼.. 
제가 socket()를 사용할때,

if(Server_Socket=socket(....)==IV..._ERROR).....

이런식으로 했었죠..

그래서, 글을 읽자마자 확인해보구,, 이상하다 싶어서,

기냥 밖으로 빼보았죠..

Server_Socket=socket(...);

if(Server_Socket==IV.._ERROR)... 
이러니까 되더군요..

근데 아마도, if문쓸때,

if((Server_Socket=socket(...))==IV..._ERROR)...

이런식으로 해도 되나???

음.. 
음..

네트웍 플밍을 API 소켓으로 플밍하셨나요?

제가 API소켓으로 만들었을때 방법을 알려드리죠..

연결이 해제되었으면, 읽는 도중에 에러가 발생할텐데요..

error=recv(...);

이때 error에 주로, 읽힌 바이트가 리턴되는데,

가끔가다가 SOCKET_ERROR이 리턴되는 경우가 있거든요.. 
그때, 마지막 에러를 체크해서,

클라이언트쪽은 10054번에러(뜻이 뭐였더라 --;)

서버(클라이언트하나하나를 상대로 있는 소켓들)에서도 역시

10054번 에러가 나더라구요..

음..

그럼,, 참고가 되길.. 
안녕하세요 이홍기입니다.

서버에 소켓 접속한 클라이언트가 죽었는데 netstat로 살펴보면

ESTABLISHED상태이고 계속 살아있는 경우가 있습니다.

랜환경에서 테스트해보는 방법은, 접속한 상태에서 클라이언트의

컴퓨터에 연결된 네트웍 케이블을 뽑아보시면 됩니다. :)


이럴땐.. socket쪽엔 에러가 안나더군요. 물론 제가 잘못 알수도

있지만., 에러체크가 잘 안되더군요. 
이럴때를 대비해서.., 일정시간 패킷이 오지 않으면 강제로

socket을 close시켜주는 방법이 떠오르더군요.


잡담성 글입니다. 
비정상적인 클라이언트 종료시..
예를들면 선을 뽑는다던가 하는경우에는

그 소켓에 write 했을때 write 당시는 문제가 없는것처럼 나오지만
timeout 될때까지 TCP 레이어에서 받아야할 응답(ACK)이 오지않을경우
알아서 소켓을 죽여줍니다..
Async 에서는 FD_CLOSE 가 날아오더군요.

read 에서 반환값 검사로도 알수 있을듯 합니다.

- Testors 

가령 IP 100.100.100.0 ~ 100.100.100.255까지 컨넥트를
시도한후 성공하는 IP를 추려낼려고 합니다
근데 connect에서 서버가 없는 IP에시도하려하니까 일정시간의
블록킹이 걸리더군뇨
블록시간이 짧으면 상관없는데 어떤 IP는 40초이상 걸리더군뇨
더 짧게 Timeout을 설정할려면 어떻게 하면 되죠?
간단한 예로 보여주시면 감사
그럼 
일정 주소영역에서 서버를 scan하는 방법을 사용할때는 보통 UDP로 하는게

많습니다. TCP의 connect는 별로 적절한 방법이 못됩니다.

UDP로 원하는 호스트들에 패킷을 날려보고 응답된 패킷을 읽어보면 IP를

알아낼 수 있지요.

UDP는 TCP와는 달리 무자게 간단하니까.. 만드시기 쉬울겁니다.

여튼 UDP로 서비스 검색하고 가능한 서버리스트를 만든뒤 Connect하면 되겠죠.. 
실제의 connect는 TCP로 사용하는데 connect를 위한 UDP를 동시에
운영하라는 말씀인가요?
그러면 TCP/UDP동시에 사용 ? 
음.. 김영호님 말씀이 가장 효율적인 방법이 될 거 같습니다.
비록 두번의 connect 요청과 socket 호출이 이루어지지만..
UPD는 피어(peer)와 연결이 이루어지는 것이 아니므로, connect에
따른 딜레이가 없을테니..
일단 udp 소켓으로 메시지를 범위의 ip에 뿌리시구..
일정 시간동안 응답이 오는 경우의 ip를 구해서 갖고 있다가
tcp 소켓으로 연결하심 되겠습니다... 

혹시 visual c++에서 mfc나 함수를 이용해서 바로

서브넷마스클를 알수 없을까요....

레지스터리를 건들지 않고...

ip는 소켓에서 알수 있는데....

서브넷 마스크만 없더군요....

혹시 아시는 분이 계시면 꼭 알려주세요....

제발 부탁드릴게용...... 


네트웍 초보 질문드립니다.
주로 tcp로 개발하시는데 저는 속도 땜시 udp를 선택했는데요.
서버와 클라이언트간의 프레임 속도가 다르면 딜레이 되서
패킷이 도착하는데요.
간단히 polling을 사용했는데 잘 안돼네요.
udp에서는 복잡하게 thread를 안 써도 될 것같은데..
ping 을 계산해서 기준 시간 안에 보낸 패킷을 계속
읽는 것도 생각해봤는데 왠지 미덥지가 안네요.
그럼... 
시스템 현재 TCP/IP가 둘이상이면 socket이 TCP 또느 UDP 모두 어떤 TCP/IP에

접속을 시도하는지? 임의로 특정TCP/IP를 지정하거나 우선권을 지정할 수

있는지 
소켓의 경우, listen 소켓 바인딩 할때,
ADDR_ANY 를 IP에 넣어주는 경우가 많은데..
원하는 특정 IP를 넣어주시면 해당 IP에 일어나는 소켓
이벤트만 처리할 수 있습니다.

그러시면 되는거 아닌가요?
^^ 
음. 질문 해주신 것은 이미 최인호님이 답변해 주셨으니 넘어가고..

두 TCP/IP 그러니까 두개의 네떡 망을 쓰고 두개의 IP 를 가졌다고
예상하는데. 트래픽 로드 밸런싱에 대해 말씀드리겠습니다. 질문에 대해
별로 벗어나는 글도 아닐수 있겠군요.

NT 에도 마찬가지겠지만 Linux 기준으로 말씀드리자면..

우선 두개의 IP 가 할당되 있겠지요?

그리고 어떤 포트에 서비스를 하게 될텐데. Remote 에서 그냥 주소만 다르게
그리고 포트는 같게 접속하면 RX (받는) 패킷은 해당 IP 대로 들어옵니다.
하지만 TX (보내는) 패킷이 문제죠. 
RX/TX 패킷을 적절히 나뉘어 주는것을 load-balancing 이라고 하는데, RX 의
경우에는 사용자가 알아서 들어오거나 혹은 망쪽에서 static-routing 을 걸어
로드 밸런싱 할 수 있습니다.

TX 패킷은 OS 나 소프트웨어 차원으로 (하드웨어적으로는 가능할지 모르겠
습니다만. 좀 비싸겠죠 아마-__-?) 해결해 주어야 합니다.

음. 저희 서버는 노가다로 static-routing 테이블을 구성해서 로드밸런싱
했습니다. 눈으로 직접 보면서 로드밸런싱을 꽤나 맘대로 할 수 있지만..
노가다가 좀 심하죠. :)

어짜피 국내 서비스를 시작으로 하실 거면 IP 블럭이 그렇게 많지 않으니
(ISP 마다 따로 구성해주어야 하는 불행함이 있지만)
static-routing 테이블을 구성해 로드 밸런싱하는 것도 그다지 나쁜것
같지도 않습니다. 

그럼.

-비엽

TCP/IP 프로토콜이 두개 이상 이라면
당연히 주소도 두개 이상이 됩니다.
NIC 당 최소 한개의 IP를 지정해 주게 되지요.

이렇게 되면 어느쪽이 접속을 받게되는가.. 는 아주 간단하지요.
IP가 다르니까요~!
클라이언트가 어느 IP를 적어주느냐에 따라에 달렸지요..

- Testors 
소켓프로그래밍으로... 파일 다운로드되는 프로그램을 만들려구 하는데요...

음... 이런 프로그램 소스가 어디 있을거라구 생각하거든여...

소스스가 어디있는지 가르쳐 주시면 정말 감사하겠습니다...

근데 제가 영어가 짧아서여... msdn 이나... codeguru에서는 애를 많이 먹거든여...

가능하면... 한글로 되어있는...^^

그럼 이만...
저번에 질문 올렸던 박상균입니다.
지금 네트워크 게임짜는 데요...
상대방에게 보내는 메세지 구조체에 몇가지를 더 낑거넣었더니
아예 메세지가 상대방에게 전달이 안되는 겁니다....
typedef struct
{
int x; //Wraith의 초기 좌표
int y; //Wraith의 초기 좌표
int F_Direction;
POINT m_Pos[50]; //Wraith의 미사일의 위치
bool m_IsInitialize[50]; //미사일은 초기화되었는가?
int m_Direction[50];//미사일의 방향을 가리키는 배열
int m_Index;
} WRAITHPDU, *LPWRAITHPDU;
대충 이런식으로 구조체를 만들었었는데...안돼더라구요... 
여기서 배열 50개짜리 변수 3개를 빼니까...잘 돼구요...
음냐....
과연 메세지의 크기는 얼마까지 가능한가요.....
그리고 네트워크의 속도체크는 어떻게 하며....
속도에 맞는 메세지를 만들려면 어떻게 해야 하는지요....

.
.
.
.
아무것도 모르면서....혼자 네트워크 프로그래밍을 시작하는 규니가...
흑.흑~~ 
안녕하세요? 회사 아이디를 쓰고 있는 레이옷입니다.

여러분, 이런 생각 해보셨죠?

보통 소켓에서 데이터를 읽을 때, 함수에 오토 변수로 버퍼를 선언하고

일단 여기다가 한번 읽은 다음 이것을 각 플레이어마다의 입력 버퍼에

복사해서, 파싱을 해가지고 하나의 명령을 끄집어내서 처리하자나요..

char buf[BUFFERLEN];
int nread = read( fd , buf , BUFFERLEN );
memcpy( &input_buffer[tail] , buf , nread );

즉 이때 복사가 2번 일어나게 되죠. 소켓의 receive buffer에서 buf로 
한번 복사되고, 다시 플레이어의 입력 버퍼로 한번 복사되고.. - -;

빠를수록 좋은 겜 서버에서 불필요한 2번의 복사라니.. 우웃.. 안돼~~

더군다나 소켓에 들어있는 데이타가 버퍼보다 많을 경우, 여러번 읽어

줘야 하기 땜시로.. (즉 버퍼는 1k 인데 소켓에 8k 의 incoming 데이타가

있다면.. 총 16회의 복사가 이루어진다는 소리죠. - -;)

==

그래서, 저는 두번째로 이런 방법을 써 봤습니다. 소켓에 얼마만큼의 
데이타가 있는지 ioctl(FIONREAD); 를 써서 알아본 후, 있는 만큼을

바로 플레이어의 입력 버퍼로 복사했찌요. 흐흐흐..

int available = 0;
ioctl(fd , FIONREAD , &available );
read( fd , &input_buffer[tail] , available );

이렇게 하면 복사가 단 1회만 있으면 되니깐.. 웬지 좋아보이더군요.

==

근데.. ioctl(FIONREAD); 가 얼마만큼의 비용이 드는지 모르겠더군요.

흠.. 웬지 수상했습니다. 이것도 역시 시스템콜이니까.. 혹시 복사보다 
더 비용(cost)이 많이 들면 어쩌지.. 하는 불안감이 생기더군요..

어디에도 이 시스템콜의 부하에 대해서 설명해놓은 데가 없어서리..

==

그래서, 저는 세번째로 이렇게 했습니다. 웃긴 이야기인데... 일단

입력 버퍼가 가득 찰때까지 읽어봅니다. 그래도 계속 읽어진다면,

버퍼에 아직도 데이타가 남아있다는 소리이지요. 이때 이제 ioctl()

을 사용해서 남아있는 데이타의 크기를 계산합니다. 이게 0보다 크다면 
어쩔 수 없이 버퍼를 증가시켜야 겠지요. - -;

int nfree = get_input_buffer_free_size();
int nread = read( fd , &input_buffer[tail] , nfree );
if ( nread == nfree ) {
int available = 0;
ioctl( fd , FIONREAD , &available);
if ( available > 0 ) {
resize_input_buffer(available);
read( fd , &input_buffer[tail] , available );
}
}

이렇게 하니까,ioctl()이 호출되는 확률을 확- 줄일 수 있었습니다. 
물론 효과는 더 좋아졌다고 생각만 하고 있찌요. 카카카카.

대신 소스가 복잡해져서.. 버그가 출몰해서 고생을 많이 했습니다.

(아직도 버그 하나가 속을 썩히고 있는데 크게 피해는 주지 않는

놈이라서 천천히 해결하려고 마음먹고 있습니다.)

==

흑. UDP 때문에 스트레스를 많이 받고 있는 차에 이렇게 그냥 한번

남들 다 아는 이야기 써 봅니다. 크크크..

그럼 여러분 모두 메리크리스마스.... 
TCP 라면 stream 소켓이니, 나눠서 순차적으로 써주시면 되고,
UDP 는 getsockopt()로 보낼 수 있는 최대크기 얻어서,
그 이상 크기는 보내면 안됩니다.. 
어떤 책에서 봤었던 것 같은데,
프로토콜 하나(패킷??)의 크기가 클 경우.
한번에 읽어들이지 않고
여러번에 걸쳐서 나누어서 읽어들이는게 좋다고 그러더군요..

그러니까..
while(recv(줄줄줄) != SOCKET_EORROR);
와 같이 말이죠..
뭐 SOCKET_ERROR가 데이터가 없을 때만 나는 게 아니니깐
조금 더 복잡해져야겠지만요..

제가 이런 글을 올리게 될 줄이야... 
메시지 크기는 얼마가 되던지 상관이 없습니다.
다만 큰 메시지는 분할이 되지요. 따라서, 쓸데없는 라우터에
부하를 주므로, 가급적이면 큰 메시지는 피하는 게 좋습니다.
제 테스트 결과로는 랜 상에서 ms 윈도우의 tcp/ip는
약 7k 바이트가 하나로 넘어갑니다..
그 이상이라면, 랜 상에서도 분할이 된다는 거죠.
물론, 실제 인터넷 상에서는 더 작게 분할될 수도 있습니다.
(당연히 더 작게 분할됩니다... ㅜㅜ)

따라서, 메시지의 사이즈가 크건 작건,
송수신시에 루프를 돌리면서 하던가, 사이즈를 확인해야 합니다.

가능하면 작은 메시지가 좋다는 것은.. 또 문제가 생깁니다..
작은 메시지를 자주 본내다면 배보다 배꼽이 커지게 됩니다..
헤더의 사이즈만해도 tcp 20바이트, ip 20바이트 이렇게 
40바이트가 넘어갑니다.
그래서, 최선은.. 여러분들께서 말씀하시지만..
가급적 메시지를 자주 보내지 않도록 하면서..
보내는 메시지의 사이즈는 최소로 하는 겁니다..
(이부분이 메시지 설계 상에서 가장 어렵습니다.. ㅠㅠ)

그럼 
잡담입니다...

저같은 경우는.. 버퍼를 최대 메시지 사이즈 이상 잡고 쓰는게
좋다고 생각합니다. 서버의 메모리야 신경쓸 필요가 없을테니.
복사를 두번 할 필요 없이..
메시지를 다 받아질때까지 버퍼에 계속 밀어 넣고..
다 받았음을 확인하면, 이때 한번의 복사로 해당 클라이언트의
메시지 큐에 넣어 버리지요.
저의 경우 최대 사이즈라고 해 봤자... 몇 k 안되니까..
메모리 복사는 사실 암호화 계층이나 이후에도 많은데..
소켓 계층에서까지 복사를 시키는 건.. 좀.. 그렇더군요.

그럼. 
TCP 에서 메세지 분할이라면,
인터넷을 거칠경우 여러 네트웍들을 지나게 됩니다..
거치게 되는 많은 네트웍들에는 저마다 MTU가 잡혀 있는데
결국 전송 가능한 최대의 패킷크기는 거치게 되는 네트웍들중
최소의 MTU 값이 되지요.

효율을 따진다면 최소 MTU값만큼을 보내주면 되지만,
TCP의 Connection 이란것은 물리적인것이 아니기 때문에
연결 된 후에도 경유하는 회선은 얼마든지 바뀔수 있습니다.

전송량에서의 효율만을 따진다면 이것저것 가릴것 없이
대량의 메세지를 한꺼번에 써버리면.. --;
저절로 최적의 크기로 나누어 지게 되겠죠.
하지만 게임에서 이렇게 할수있는 경우란 흔치 않죠. 
피해야 할것은 아주 작은 메세지들을 여러개 보내느것 뿐이라고 생각합니다
이것 피하는건 그다지 어렵지 않지요.
시간차가 그다지 나지 않는 메세지들을 버퍼링해 같이 날려주면 되니까요.

- Testors

ps. 크리스마시군요... 모두 좋은시간 되세요.. 
네트웍란에 질문은 첨이네요. ^^;
크리스마스, 새해도 이미 맞이한 시점에서, 정말 늦게 쓰는 변이 아닌가 싶군요. :)

그런데, 불행히도, 아래에 있는 내용은 대부분 다이렉트 플레이에 관한 것인지라,
재작년 이후로 다이렉트플레이를 안만진 상황에서 답변을 해드릴 수 없어서.. "뭐 토

달거 없나.." 찾아보니까 하나 발견되네요. 헐헐헐..

그럼, 암튼, 이제 토를 달아보죠..

태호님이 쓰시는 방법을, TCP 소켓에서 쓰면, '패킷이 쪼개지거나 뭉쳐지는' 문제가

발생합니다. (이 문제에 대해서는 지나간 글을 확인해보세요. 아울러, 그 글을
읽어보시면, 더 좋은 방법을 확인하실 수 있을겁니다.)

하지만, 태호님의 방식은, UDP 소켓에서 잘 돌아갈겁니다. 
127.0.0.1은 자기 집에서 테스트 할때 쓴다고 알고
있거든요(아니어도 바꾸면 되니 반론은 제기하지마세요^^)
그런데 믿을수 있나요?
그니까 제가 체팅 프램을 만드니까요.
제가 서버한개 틀어놓고
여러개에 클라이언트를 연다고 침니다.
제가 해본결과 꽤 괜찮게 돌아갔거든요.
그런데 저희집이 서버가 않돼요(두루넷입니다.)
그래서 제가 진짜 서버를 해보지 못했어요.
127.0.0.1에 많이 접속 한거랑.
진짜 서버에 많이 접속한거랑 틀립니까?
속도 차이는 나겠지만. 127.0.0.1에 잘돼면 잘돼나요?
답변바랍니다.^^
자신의 로컬 서버 주소인건 맞구요.

으음.. 로컬에서 많이 접속한거나 리모트에서 많이 접속한거나 프로그램의
부하는 같을 겁니다. 단지 로컬에서 테스트 하실 때 send 와 recv (혹은 read,
write) 을 쓰셨다면 패킷이 짤리는 현상을 전혀 경험하실 수가 없을
겁니다. (아.마.도.)

패킷이 짤리는 현상이란,

보낸 놈(send)은 다 보냈는데

받는 놈(recv)이 찔끔찔끔 받는 현상입니다.

그래서 보통 받는 놈의 경우 찔끔찔끔 받아서 뭉쳐서 처리해주는 작업을 
해주어야 합니다. 간단한 채팅 프로그램이라면.. 위의 처리는 필요가 없고
텍스트 MUD 처럼 \n 문자가 올 때까정 recv 하면 되겄군요.

그럼

-비엽 
흠.. 답변 감사하구요.
제가 아직 않해봤기 때문에 또 다시 모르는
부분이 생겼내요..
질문은요.. 127.0.0.1을 쓸때는 다른 정보가 않오더군요.
(제가 전에 케이블 통신을 해봤는데. 이건 노이즌가? 이런
것도 조금 있었는데요. -_-;; 아닐지도 프렘을 넘 무식하게
해서리^^)
아! 그리고 recv로 무한루프 돌리기는^^
제가 원래 무한루프돌리기를 싫어해서
패킷을 만들예정
대충에 패킷
[대화글][2]안녕~~
이런식으로( 2라고 쓰여진곳은 인트형 말의 길이
패키을 보고 말의 길이 많큼 받아졌으면 처리하면 좋을거
같아요. 
안녕하세요.

엉뚱한 주소값을 넣고 connect()를 호출하면 블록이 됩니다. -_-;
예전에는 결과에 상관없이 WSAEWOULDBLOCK 값을 체크해서 처리할 수 있었는데..
쩝..뭐가 어떻게 다른진 몰라도 connect()를 호출하면 도저히
다음줄로 이동할 수가 없네요.
WSAEWOULDBLOCK 는 블록되어야 할 상황인데,
async 모드로 세팅되어 있어서 바로 리턴했다.. 라는 메세지인데요,
async 모드라면 잘못된 주소를 넣어도 바로 리턴될텐데요..? 

꺼이꺼이~~ T_T 도와주세요. 
제가 요즘에 스타형식에 네트워크를 구상을 했는데요.
그거에서. 꼭 알아야 할거 같아서요.
ip주소를 얻는 법을좀 가르켜 주세요.
제가 책이 없어서 여기다가 도배를 ㅠ_ㅠ
죄성 하구요. 빠른 답변 기대합니다~~ 

접속자 IP는 해당 소켓에 getpeername() 을 호출하시면 얻을수 있습니다..

책을 하나 사심이.. --; 
MFC의 CSocket 클래스나 ASyncSocket 클래스로 패킷을 받을경우인데요...
서버에서 Send()를 사용하여 한번에 100K 정도되는 대용량을 보냈을때
클라이언트에서는 이를 어떻게 받아야하나요?
CSocket으로 받는 경우 Receive()가 완료될때까지 블럭킹되는 것으로 아는데..
그렇다면 Receive()가 완료되었을 경우 100K를 모두 받았다는 말이 되는겁니까?
혹시 서버에서 한번에 100K를 모두 Send()한다고 치더라도...
클라이언트에서 받을때는 OnReceive 가 여러번 호출되는건지 궁금합니다.
즉 패킷이 여러번 잘려서 도착할때마다 Receive()해야하는지 알고싶습니다.

만일 ASyncSocket 이라면 여러번 Revceive()하는것은 당연할거라고 생각하는데
CSocket 에서도 그런지 아시는분은 답변해주셨음 합니다. ^^

P.S 추가합니다.
CSocket과 같은 블럭킹소켓이라면(실제로는 넌블럭킹이겠지만) 한번에 100K를
Send()하면 단 한번의 Send()로 100K 모두 전송이되겠죠? 
그런데 CSocket의 경우 내부적으로 ASyncSocket을 사용하는것으로 압니다.
결국 한번에 Send()되지 못하고 내부적으로 블럭킹이 해소되면
조금씩 조금씩 보내서 한번의 Send()로 완료되는것 처럼 보이는겁니까?
그래서 클라이언트에서 OnReceive()가 여러번 호출되는 것인지요?

에구 복잡다.... 
아래에 질문한 패킷 도착 형태는 혼자서 이것저것 테스트 한 결과...
예상과 비슷하다는것을 알았습니다. 그런데 Send는 약간 다르더군요.
혹시나해서 한번에 1M 정도되는 데이터를 Send했습니다.
(Local LAN 상에서 테스트한 것입니다)
확인해본 결과 Send()는 1M도 한번에 되더군요.
(참고로 MFC의 비동기 소켓 클래스인 CASycnSocket 을 사용하였습니다)
그러나 수신측에서는 잘못된 연산에러를 일으키며 다운됐습니다.
원인을 분석하려고 OnReceive()에서 데이터를 받은양을 출력해주는 대화상자를
띠우니까 8056 바이트씩 쭉쭉 들어오다가 버퍼가 다 차서 다운되는것 같았슴다.
즉 데이터가 여러번 패킷 분할되어서 계속해서 들어온다는 이야기인데요..
문제는 데이터가 수신되면 SendMessage()를 사용하여 데이타를 수신하라는 메세지를
날려줬는데... (메세지를 받으면 버퍼를 읽고나서 비워줍니다)
버퍼에 데이터를 비우는 속도보다 OnReceive()가 더빨리 발생합니다.
OnReceive()가 호출되면 Receive()를 사용하여 데이터를 받고나서 SendMessage()로
알려주기도 전에 또다시 OnReceive()가 호출되는것 같습니다. 
그래서 버퍼를 비우기도 전에 자꾸 Receive()하게되서 버퍼가 꽉 차버리는것 같네요
버퍼의 내용을 비우고 나서 다시 Receive()를 하게끔하는 방법은 없을까요?
그리고... OnReceive()는 메인 윈도우의 메세지 루프 상태와 상관없이...
수신 데이터가 있다면 무조건적으로 호출되는 것입니까?
다시 말하면 OnReceive()를 다 처리하기도 전에 또 OnReceive()가 호출되기도
하는 것인지 궁금합니다......
좀 급하니까 아시는 분은 답변 주셨으면 합니다... ㅠ.ㅠ 
음.. 1메가를 한큐에 보냈는데 쪼개져서 받아졌다면 TCP겠네요.
님이 걱정하신것처럼.. 음.. 보내는넘은 마구 보내고
받는놈은 다 처리하지 못해서 에러나는일은 없습니다.

1메가를 통짜로 보내게 되면 어디선가 쪼개서 보내는데요,
첫번째 블럭을 보냈다고 했을때,
받는쪽에서 그 첫번째것을 받았다는 답신(ACK)를 보내주기 전에는
두번째 블럭은 안보내고 대기하게 됩니다.
(가끔 클라이언트쪽에서 효율을 위해 자기가 보낼 데이터를 300ms정도 기다렸다가
데이터 끝에 ACK를 붙여서 보내기도 합니다. 이래서 TCP쪽은 예상치 못한
지연시간이 생기기도..)
만약 대기하고 있는 데이터가 많아서 내부버퍼가 가득차면
Send 시에도 블럭이 일어나게 되지요. 뭐 드문경우입니다만.

아무튼 보내는넘은 마구 보내고 받는넘은 받다가 허덕여서 에러나는건 
소켓 라이브러리 수준에서는 일어나지 않습니다.. 가 요지입니다.
원하시는 답일진 모르지만, 참고하세요.

- Testors 
패킷이 쪼개지는건 테스트를 통해서 알게 되었습니다.
그런데 1M를 한꺼번에 Send하면 수신측에서 다운되는 이유를 모르겠어요.
작게 나누어서 여러번 센드하면 문제없이 받던데...
100K로 쪼개면 잘 받더군요. 그런데 1M를 한번에 날리면...
수신측이 다운됩니다.
물론 수신버퍼는 1M를 충분히 받고도 남을만큼 넉넉하게 준비해둔 상태였구요

내부 네트웍상에서 테스트해봤습니다.
버퍼 관리를 잘못해서 그런가?? 긁적...
버퍼는 이상이 없었는데.. 흑~

아참... 1M를 한꺼번에 전송을 해도.. 수신측에서 받을때마다 메세지박스를
띠우니까 약간씩 딜레이가 되서 그런지 다운이 안되더군요.
그냥 받으면 다운됨... (혹시 Receive 메세지가 폭주하여 윈도 메세지 버퍼가
꽉 차버린건 아닐지...) 
흑.. 몰겠어용...코드 어디에서 다운되나요?

재훈님이 작성한 버퍼쪽 코드인가요..
아니면 MFC 클래스에서 다운되나요..?

다운되는곳 근처의 코드를 같이 긁어 올리시면 문제 파악이 쉬울듯 싶네요. 
udp소켓에서

윈도우 메세지 이벤트를
받을라믄 어케해야 하는지 
윈속을 공부하고 있는 초보자 입니다........

accept 와.. select.. recv 의 관계가 잘 이해가 안되가지구요..

accept 할때 select 로 검사를 해서 하구요...
recv 할때도 select 로 검사를 해서 하구요..

두가지 모두 readfds 를 검사해서 사용하는데요.. 그렇게 되면
데이타가 와도 accept 로 들어갈 경우가 있는건가요 ?
연결 요청이 들어올대 recv 로 갈수도 있게 되는건가요 ?

... 요 부분이 궁금해서 다음으로 넘어갈 수가 없어요.. -_-;

그리구요.. listen 함수에는 1~5 사이의 값을 넣어야 한다고 하는데.. 
5명 이상은 대기할 수 없게 되는건가요 ?... .. .. . .
(listen 을 꼭 해줘야 하나요 ? )


이상입니다...... . . 
TCP 소켓을 만들면 소켓 디스크립터가 하나 나오죠.
그게 accept 받는 소켓입니다.
거기에 READ FD 플래그가 걸리면 접속요청이 있다는 것입니다.

접속요청 받아 accpet 받으면 또 소켓 디스크립터가 나오죠.
그건 클라이언트와 연결된 소켓입니다.
그것에다 I/O 하면 되죠.. 다른 소켓이니
READ 가 겹치진 않지요.

UDP 의경우는 "연결"의 개념이 아예 없으므로,
READ는 모두 패킷 도착한것들입니다.
recvfrom 에서 보낸이의 주소, 데이타가 같이 넘어옵니다.

listen 의 경우는 accept 사인이 들어왔을때 제대로 처리만 해준다면
5정도 잡아줘도 별다른 문제는 없습니다. 
스타를 하다가 문득 UDP는 어떻게 연결 종료를 알아챌까 궁금해집니다.

TCP는 클라이언트마다 핸들(SOCKET)이 있어서 각 핸들마다

연결이 끊기면 이벤트나 메세지를 발생시킬 수 있는 데(윈도 기준)

UDP는 클라이언트마다 핸들이 있는 것도 아니고

특별히 연결 되어 있는 것도 아니니까

아예 처음부터 끊긴다는 개념이 없는 것 같은 데요...

하지만 어쨌든 게임에서는 접속 종료를 체크해야 되고,,

또 실제로 스타에서는 Alt + Tap를 눌러서 포커스를 옮기거나 
아니면 아예 시스템을 꺼버리면

곧바도 화면이 어두워지면서 창이 뜨고 4x초를 기다린 후

드랍을 할 수 있게 하죠...

다시 말해서 스타에서는 UDP를 쓰지만 곧바로 연결이 끊긴 걸 안다는 거잖아요.

어떻게 하죠??

네떡 초보 
확실하진 않습니다만 주기적으로 메시지를 서로 주고 받으면 알 수 있지
않을까요?

예를들어, A,B가 대전중일때 주기적으로

A가 "나 A인데 살아있나?" 라는걸 보내고
B도 "나 B인데 살아있나?" 라는걸 보내면,

주기적으로 이걸 받아야지 못받으면 일정시간을 기다리다가
상대방으로부터 접속이 끊겼습니다라고 알려주면 되지 않을까요?
구체적으로 구현하려면 조금더 세밀하게 할수도 있겠지만
다른 방법이 또 있을려나?

아이디빌려쓰는쥐. 
UDP 에는 "접속" 이라는 과정 자체가 없습니다.
따라서 "접속종료" 또한 없습니다.

스타가 UDP 포트를 하나 열었다면,
플레이중인 플레이어가 아닌 다른 플레이어가
목적지 주소 적어서 날려주면 게임에선 그 메세지 받게 되죠.

접속종료가 없으니.. 처리방법은 단지,
Option 의 Network 부분에서 설정된 Latency 의 시간만큼
한명의 플레이어라도 메세지가 도착 안했으면
게임을 잠시 중단시킵니다.
중단시간이 몇초 이상 넘어가면 디스 창이 뜨고..
이때 UDP기때문에 메세지가 날아갔을수도 있으니,
기다리는 동안 주기적으로 몇번째 프래임 메세지 못받았으니 다시 보내달라고
요청하기는 하죠. 
TCP를 사용해서 데이터 전송시 중간에 네트웍이 죽을 경우 프로그램에서
처리하지 않아도 자동으로 재전송하게 되나요?

ping을 때려보면 중간중간 패킷이 도착하지 못했다는 메시지를 확인 할 수
있는데요.
혹시 이와같이 reliable한 TCP라도 중간에 패킷 하나가 아예 전송이 되지
않는 경우가 있을 수 있는지..? 궁금합니다. 그럼.. 
간단하게 말씀드리죠.
우선 TCP에서는 하나의 segment를 보낼때 마다 timer를 작동시켜서
time out이 될때까지 ACK가 오지 않는 다면은 다시 재전송을 하게 됩니다.
다음번에는 timer의 시간을 좀더 길게 잡아서 보내구요..
그렇다고 계속 무한대로 보내지는 않겠죠?
제가 실험해 봤을때는 어느정도 시간이 지나도록 계속해서 전송 실패를 하게
된다면은 알아서 연결이 끊어 지더군요(winsock에서 default로 setting 되어
있을 경우 30초 정도 후에)..
끊어 졌다는 메시지를 application에게 전달 할 겁니다.
참고가 되셨기를...
--jadoo 
10바이트를 send했다고 할때 리턴값이
WSAEWOULDBLOCK나왔다면 10바이트 모두를 재전송해야하는건가요?
지금껏 아무생각없이 생각해보니 이렇게 하면 안되겠다 싶어서.
현재 비동기 윈속을 쓰고 있고 send하면 리턴값으로 보낸 바이트
가 나오는거로 아는데요.
생각해보니 이상한게 비동기소켓인데 바로 몇바이트 보냈는지
리턴된다는것도 그렇고 블럭되었다면 10바이트 전송 전체가 블럭
된건지 그 중 일부는 보내고 나머지 부분에 대해서 블럭된건지...
답변 부탁드립니다. 
비동기 소켓에서 send()를 하다 블록킹이 뜬 경우 보내고자 한 메시지를 보내던

중에 블록 걸렸단 의미입니다. 일부는 보내고 일부는 못보냈다는 뜻이죠.

send()에서 리턴된 값이 보낸 바이트 수이고 그 이하는 보내지 못한 거죠.

이런 경우는 남은 데이터를 큐에 넣어 놓았다가 FD_WRITE메시지가 올때까지

전송을 미루어 둬야 합니다.


프로그램은 진행되고 코드상으로는 메시지를 보내야 하는데 네트웍 블록킹

상황으로 실제적으로는 메시지를 보낼 수 없는 경우가 발생합니다. 이럴때를
대비해서 소켓의 전송 데이터 큐를 만들어 놓는 겁니다.

큐에 순서대로 쌓여있는 데이터들은 블록킹 상황이 풀렸다는 FD_WRITE 메시지

가 수신되면 그때 전송하면 되죠. 물론 큐에 있는 데이터를 보내다가 또 블록킹

이 뜰수도 있으니 그에 대한 대비도 해야 합니다. 
답변 감사합니다.
근데 제가 질문한 의도와는 약간 벗어난 듯 하여 재질문합니다.

물론 수신큐,송신큐를 만들어서 fd_write가 발생하면 다시 보내고 있습니다.
음..그러니까 제 질문을 다시 풀자면..
이거 제가 잘못짠건지 모르겠는데 send()함수의 리턴값이 SOCKET_ERROR일때
WSALastError로 블럭인지를 판별하고 있습니다.그러니까 send()의 리턴값이
0보다 크면 WSALastError()을 안한단 소리고....
음.그러니까 다시 풀면 리턴값이 0보다 큰 경우는 문제가 안생겼다고 가정
한다는 얘기죠.일단 큐에서 send()에서 리턴한 길이만큼만 데이타를 뽑아내
고 fd_wirte가 발생했을때 남은 부분을 보냅니다만.
블럭상태인지는 0보다 클땐 체크를 안한단 얘기입니다.
지금껏 랜 상태에서 테스트를 했었기 때문에 문제가 전혀 없었는데 문득
이상한 생각이 들어서 말입니다.
send()에 넣어준 메시지 길이보다 리턴한 길이가 작다면 블럭이 걸린것으
로 간주해야하는건가요?
답변 부탁드립니다.

프로그램에서 100바이트의 데이터를 보내기로 해서 send(100)을 했다고 하면,

한번의 send()함수로 100바이트를 모두 보낼 수 있다는 보장이 없기 때문에

100바이트를 다 보낼때까지 send() 함수를 콜하면서 루프를 돕니다. 그러다가

반환값이 블록이면 블록킹이 걸린것이고, 끝까지 루프를 다 돌아서 모든 데이터를

다 보내며 성공한 것이죠.

다음 코드를 보시면 참고가 될 겁니다. 
메시지는 cData[] 배열 안에 저장되어 있습니다.
기타 큐 저장 관련 함수는 제가 구현한 것이므로 신경쓰지 않으셔도 됩니다.
물론 모든 데이터의 전송을 보장하기 위해서는 전송 메시지 큐를 반드시 구현해야만
합니다.

iOutLen = 0;
while (iOutLen < iSize) {

iRet = send(m_Sock, (cData + iOutLen), iSize - iOutLen, 0);

if (iRet == SOCKET_ERROR) {
WSAErr = WSAGetLastError();
if (WSAErr != WSAEWOULDBLOCK) {
// 소켓에 에러가 발생했다.
// 복구가 불가능하므로 연결을 끊어야 한다. 
m_WSAErr = WSAErr;
return DEF_XSOCKEVENT_SOCKETERROR;
}
else {
// 블럭상태이면 더이상 보낼 수 없으므로
// 남아있는 데이터를 전송 큐에 등록하고 리턴
if (bSaveFlag == TRUE) {
iRet = _iRegisterUnsentData((cData +
iOutLen), (iSize - iOutLen));
switch (iRet) {
case -1:
// 할당할 메모리가 없다.
// 이경우는 복구할 방법이 없다.
return DEF_XSOCKEVENT_CRITICALERROR;
break; 
case 0:
// 큐가 가득찼다. 이 소켓
// 클래스는 삭제되어야만 한다.
return DEF_XSOCKEVENT_QUENEFULL;
break;
case 1:
// 정상적으로 데이터를 등록했다.
break;
}
}
return DEF_XSOCKEVENT_BLOCK;
}
} else iOutLen += iRet;

} 
참고가 되면 좋겠군요

제가 SOCKET 을 찾아 봤는데
unsigned int 더군요..
그럼 실질적으로는 최고 65536명을 받을수 있다는겁니까?
그렇다면.. 수정이 있어야 할듯싶네요.
책좀 추천해 주시지.. 아직 암도 않쓰셨네요.
그거하고 이거하고 답변 바랍니다. 
> 비동기 소켓에서 send()를 하다 블록킹이 뜬 경우 보내고자 한 메시지를 보내던
> 중에 블록 걸렸단 의미입니다. 일부는 보내고 일부는 못보냈다는 뜻이죠.
> send()에서 리턴된 값이 보낸 바이트 수이고 그 이하는 보내지 못한 거죠.

비동기 소켓에서 send() 블러킹 상황일때는
SOCKET_ERROR 가 리턴되지 않나요..?

- Testors 
만약에 send()함수에 한번에 100kb정도를 넣었다고 하면...
이 정도면 일단 첫번에 블럭이 걸릴거 같은데요.이렇게 가정했을때
얼마만큼은 보내고 얼마만큼은 못보내지 않겠습니까?
그렇다면 send()의 리턴값은 SOCKET_ERROR입니까? 아니면 보낸 바이트 수입니까?
지금껏 질문한건 바로 이걸 묻는것이었습니다.

1. 100바이트 보내고 나머지 99900바이트를 보내지 못했다면 일단 100이
리턴되고 다음번 send()할때(소켓이 fd_write 상태가 되기 전에) SOCKET_ERROR
가 발생한다.

2. 첫번에 SOCKET_ERROR이 리턴된다.

중 하나일것 같은데..전 전자쪽으로 생각하고 있었는데 어찌 되는것인지
정확히 답변좀..
그리고 블럭되는 경우나 접속이 끊어진 경우 외에도 send()함수에 넣어 
준 길이보다 적은 값이(보낸 바이트)이 리턴될수 있습니까?
쩝..이거땜에 딴걸 못하고 있네요.신경 쓰여서... 
send() 시에 보낸 바이트 수가 리턴될 수도 있고 곧바로 SOCKET_ERROR를 받을 수도

있습니다. 그건 네트웍 상태에 따라 달라지니까요.

100KB를 send() 했다면 50KB만 보냈다고 리턴값이 올수도 있고, 보내자 마자

SOCKET_ERROR를 받았다면 에러의 종류가 Block인지를 판단한 후, Block 이외의 에러

라면 소켓을 끊는 수 밖에 없으며, Block이면 전송 큐에 넣어 버리고 리턴하면

되죠.

만약 50KB만 보냈다고 리턴값을 받은 다음 곧바로 나머지 데이터를 send() 한다고

했을때 남은 50KB 데이터를 다 보낼 수도 있고 30KB만 보냈다고 할 수도 있고
그대로 SOCKET_ERROR가 뜰 수도 있겠죠. 그런 이유로 아래 코드에 send() 부분을

루프로 도는 것입니다. 루프를 돌면서 데이터를 모두 다 보냈다면 좋은 것이고

블록이 걸렸다면 전송 큐에 넣으면 되는 겁니다. 
nLength = m_pSQueue->View(data, nQueLength);
nLength = send( m_Socket, data, nLength,MSG_DONTROUTE );

if( SOCKET_ERROR == nLength )
{
int n=WSAGetLastError();
// 에러처리후 리턴.
// WSAWOLDBLOCK(?) 이 아니면 보통 소켓을 닫아버립니다.
}
else{
// nLength(보낸바이트수) 만큼 버퍼를 비웁니다..
m_pSQueue->Read(data, nLength);
} 
쓰고있는 코드중 일부입니다.. 참고하세요..

- Testors 
unsigned int 라면 65536 이 아니라 4294967296 일텐데요
하지만 실적으로 65536소켓 이라고 보셔도 무방합니다.
그리고 한 머신에서 65536 소켓을 핸들링 하는것 자체가
비효율적이고 무모한 짓 아닐까요.

분산처리에 관심을 가져보십시여.-_-;

-비엽 
WSAStartUp 을 call 할때 WSADATA 라는 struct를 매개변수로 넘겨주지요?

WSAStartUp 이 실행된 뒤에 WSADATA를 열어보면 WSADATA.iMaxSockets 라는

멤버에 최대 소캣 갯수가 들어있습니다. 이 외에도 윈속 버젼, 최대 패킷크기,

기타등등의 정보가 넘어옵니다.

참고가 될런지요? 
fd_read가 발생했을때 tcp내부 큐에 몇바이트가 쌓여있는지,
즉 recv()할때 한번에 몇 바이트 리드 할수 있는지 바이트 수를
알려면 어떻게 해야할까요? fd_read발생할때마다 1바이트씩 읽었
더니 lan환경에선 옆에서 왕창 보내면 난리가 나더군요.
fd_read가 끊임없이 발생해서 cpu를 독점하는 결과가..

답변 부탁드립니다.
이것은 두 소켓의 통신 규격을 프로그래머가 어떻게 정했는가에 달린 문제이기도

한 것 같습니다. 상대편에서 50바이트만 보냈다면, recv(Socket, pBuffer, 100)

하면 리턴값이 50이 반환될 겁니다. 그다음엔 아무리 recv()를 돌려도 데이터가

안오겠죠.

즉 문제는 recv() 할 당시에 몇바이트를 받을 것인가를 어떻게 지정할 것인가

인데, 이것은 저의 경우, 메시지의 형식을 처음 몇바이트는 앞으로 전송될 데이터

크기를 고정적으로 보내줌으로써 해결했습니다.

예를 들자면 처음 수신되는 4바이트는 이후로 전송할 데이터의 사이즈임을 약속하
면 처음에 recv(socket, pBuffer, 4) 를 해서 사이즈를 읽어 dwMsgSize에 저장했다

한다면 그다음 recv(socket, pBuffer, dwMsgSize)의 형태로 메시지를 수신합니다.

물론 dwMsgSize만큼의 데이터가 수신 안될수도 있습니다. 그럴때는 수신된 데이터

의 사이즈 만큼을 dwMsgSize에서 뺀 다음 다음 FD_READ메시지가 수신될 때 그 사이

즈로 수신하면 되겠죠.

소켓으로 보내거나 수신되는 모든 메시지는 쪼개지거나 합쳐질 수 있다는 점을

유념하셔야 겠죠. 또 FD_READ 메시지가 왔을때 recv()를 한번만 실행해야 하며
recv()를 두번이상 실행하면 경험상 메시지가 꼬이더군요. 이것도 주의해야 합니다.

안녕하세요?
광현임의 답변의 요지는 recv()할 때 상대방이 보낸 메시지를 모두 받지 않고
부분 부분 받을 수도 있다는 것이라고 생각했습니다.
그래서 받은 데이터의 양을 저장한다고 하셨습니다.
그러면 말씀하신 내용들이 tcp와 udp 모두에 적용되는 것인가요?
그런데 채팅 클라이언트 서버 소스를 보면 광현님이 말씀하신 내용없이
단지 버퍼의 크기만큼 recv()해 주더군요.
recv( m_s , msg, sizeof(msg));
이렇게 할 경우 광현님의 말씀대로라면 채팅문장이 부분 부분 msg에 저장되는
문제가 일어날 것이라고 예상됩니다. 제 생각이 맞나요?
한편 tcp의 경우에는 주고 받는 데이터의 내용을 보장한다고 했는데, 그렇다면
응용프로그램에서는 주고 받는 데이터의 양에는 관심을 둦 않고 충분한 버퍼만
제공하면 되지않나요?

라인편집기로 하니 버벅거리네요, 이제까지 읽기만 하다가 처음으로 질문을 
올립니다.
제작하시면서 게시판에 글도 올리시는 분들 대단하신것 같아요 !!! 
안녕하세요? 레이옷입니다.

굳이 소켓에 얼마가 들어왔는지 아시고 싶다면, 잔액조회를 해야 겠죠.

유닉스라면 ioctl(fd,FIONREAD,&size); 하시면 되겠고,

윈도우라면 ioctlsocket(socket,FIONREAD,&size); 하시면

현재 소켓에 들어온 데이타의 크기를 알 수 있을 겁니다.

(예전에도 이 글 썼지 싶은데.. - -; )

단 일반적인 경우 메시지를 받았다면 소켓에는 무조건 데이타가 있는

거고, 그냥 버퍼의 남은 용량만큼 다 읽는 게 효율이 훨씬 좋을 겁니다. 
괜히 알아서 좋을 게 없다는 거죠. (버퍼가 작아서 resize 해야 한다면

또 모르겠습니다..)


=

아래 글들을 보니 다들 메시지 기반 함수들을 쓰시더군요.

근데 웬지 전 BSD 스타일에 익숙해서리.. 암튼 윈도우의

ioctlsocket () 에 대응되는 다른 메시지쪽의함수가 있을

것도 같군요..
==

그럼 수고하세용... 
───────────────────────────────────────
우선 제가 쓰는 방법을 간단히 말씀드리죠.. 참고가 되시길..
제가 쓰는 방법은 광현님이 쓰시는 방법과 똑같습니다.
1148의 질문에 대한 답일 수가 있겠네요.
우선 각 클라이언트마다 서버에는 하나의 클라스가 있고, 그 클라스마다 그 담당
클라이언트를 위한 버퍼를 두죠, 그 다음에 fd_read메시지가 올때는 무조건 다
읽으 시면 됩니다. 그러면 다음과 같은 2가지 문제점이 발생 할 수 있겠죠?
1. msg가 짤려서 오는 경우.
광현님이 하셨던 것과 비슷하게 일단은 정해진 규격의
header를(4바이트)보고 다음에 들어왔어야 할 데이타의 양을 알아낸후 실제
들어온 데이터의 양의 크기와 비교해보고 실제 들어온 데이터의 양이 적은 경우는
읽었던 데이터를 처리하지 않고 그 버퍼에 그냥 두고 다음에 다시 fd-read가 발생
했을 때 일단은 다 읽고 (혹시 다른 msg인지 한번 체크해 봐야 겠죠?) 부족했던
만큼의 데이터를 읽어서 예전에 읽어 놓았던 버퍼에 append시켜서 그에 합당한
처리를 해주었죠. 혹시 새로 읽어 들인 메시지가 부족했던 데이터의 양보다 더
큰 경우에는 2번이 경우와 동시에 생각 하시면 될겁니다. 
2. msg에 다른 msg가 뒤에 붙어서 들어 오는 경우.
위에서 본바와 같이 일단은 다 읽어 놓고 Header를 보고 왔어야 할 데이터의
양을 체크한 후에 더 많이 온경우에는 그 버퍼에는 현재 필요한 데이터만 남겨
놓고 다음 Header를 체크해 본후 또 필요한 만큼의 양이 한꺼번에 같이 들어 왔
는지를 확인해 봐야겠죠. 그래서 완전히 들어 왔다면은 그 버퍼에는 2개의
msg가 들어 있는 셈이 되겠죠. 혹시 또, 짤려서 왔을수도 있으니 그 경우는 1번의
경우로 해결 하시면 되겠죠?

말이 너무 복잡해 졌네요. 의도대로 제대로 설명도 안된것 같구요.
그리고 1150님의 말씀대로 버퍼에 들어온 데이터를 미리 얼마가 들어 왔는지
체크해 볼수 있지만 그 함수들은 쓰지 않는 것이 좋다고 합니다.
(windows socket programming 의 책에 의하면) performance때문인지, bug가 있다
던가 해서 가급적 이 함수를 쓰지 말라고 나왔더군요. 
어쨋건 위에서 말씀드린 방법대로 해놓고, client에서 수없이 많은 msg를
짤라서도 보내보고, 엉뚱한 데이터를 뒤에 붙여서도 보내보고, 또 두가지 모두의
경우를 보내 봤을때, 아무 문제 없이 잘 수행이 되더군요.
그리고 Header가 잘못된경우에 대비해서 정해진 Header이 외의 것 이 온경우에는
1바이트씩 읽어서 버리면서 다음 바이트를 읽었습니다. 
> 그래서 받은 데이터의 양을 저장한다고 하셨습니다.
> 그러면 말씀하신 내용들이 tcp와 udp 모두에 적용되는 것인가요?

TCP 에만 적용됩니다. UDP는 데이터그램 단위의 전송으로 전송한 블럭이
쪼개지거나 하지 않습니다. 대신 큰 데이터를 보내려 시도하면 무시됩니다.

> recv( m_s , msg, sizeof(msg));
> 이렇게 할 경우 광현님의 말씀대로라면 채팅문장이 부분 부분 msg에 저장되는
> 문제가 일어날 것이라고 예상됩니다. 제 생각이 맞나요?

TCP 일경우 문제가 발생합니다.

> 한편 tcp의 경우에는 주고 받는 데이터의 내용을 보장한다고 했는데, 그렇다면
> 응용프로그램에서는 주고 받는 데이터의 양에는 관심을 둦 않고 충분한 버퍼만
> 제공하면 되지않나요? 
맞습니다. 응용 프로그램에서는 충분한 버퍼만 준비하면 됩니다.

안녕하세요 레이옷입니당...

흠. 저희는 헤더가 틀리면 그냥 짜릅니다.

호홋.. 다분히 정책적인 문제이긴 하지만..

즉, 버퍼에 쌓여있는 데이타는 모두 옳다..라는 가정 하에서,

이상한 데이타가 섞여 있을 경우라면, 로그한 후 접속을

종료합니다. .... . Invalid Protocol.. 이라고 하면서용.. :)

아무리 생각해도 헤더가 잘못되었다는 말은 cracking 인 경우외에는

없더군요. (프로토콜이 완벽할 경우 - -; ) 
==

그러나, 여전히 걱정되는 것은 호스트가 뚫리는 거랑,

DOS 공격이지요.. 흑.. 호스트 뚫리는 거야 어째 보안을

잘 하면 될 듯도 하지만.. DOS는 어떻게 막지요.. - -;

==

흠.. 글의 시작과 끝이 다르군요. 켁.. 죄송.. 
DOS공격이 어떤건가요?
음..
DOS창에서 무언가를 하는건 아닐테고..
그럼

__
이경만
PS. 아이디를 만들었습니다.
하하하 
아마도 Denial of Service의 약자가 아닌듯싶네요..
문맥의 뜻을 봐도..

패킷 열라게 날려서
서버가 과부하되서 먹통되게 만드는 걸.통틀어 일컫는 말이라고

알고있네용...

커커...보안쪽엔 지식이 별루 없어선...맞는지....

보안 신경쓸정도로 안정된 서버를 얼렁 만들 기회나 있었음

좋겠군요..총총 
재만님이 말씀하셨듯 Denial of Service 의 약잔데, 패킷을 열라게 날리는 것
말고도 단지 socket 을 의도적으로 많이 열리게 하거나, 클라이언트 명령에
반응하는 서버 및 서비스를 의도적으로 심하게 괴롭히는 변태행위라고 할 수
있습니다.

icmp 프로토콜을 이용한 ping flooding (죽음의 핑) 도 일종의 DoS 어택이라고
할 수 있겠군요.

요즘엔 ping flooding 같은게 통하는 곳은 몇군데 없습니다만. -_-;

그래픽 머드에서 IP와 포트가 노출되면, 방어막(!) 처리를 해놓지 않는 한 DoS
어택에 당하기 쉽겠군요..

그럼 
에... 전 TCP만 써 보아서 UDP의 경우는 잘 모르겠네요. 듣기로는 UDP는 보낸

메시지가 쪼개지거나 합쳐지지는 않는다고 하던데 진짜 그런지는...??? 이건

UDP를 써 보신 분의 답변이 필요한 듯...

TCP의 특성을 다시 생각해 보자면 이런 거거든요? 전송측에서 다음과 같이

메시지를 보냈을때:


send("123456789")
send("abcdefghi") 
이러한 송신이 수신될 수 있는 조합은 무지하게 많다는 것입니다. 네트웍 사정이

좋다면야

123456789 abcdefghi 보낸것 그대로 각각 2번의 FD_READ 메시지로 recv() 될

것이지만 네트웍 블록이나 기타 여러가지 상황에 따라

123 456789 abcdefghi

123456789 abcde fghi

123 456789abcd efghi

123456789abcdefgh i 
123456789abcdefghi

등등등

전송측의 순서만 유지될 뿐 어떻게 수신되느냐는 알 수 없다는 거죠.


그리고 인터넷에서 구할 수 있는 소켓 소스들을 살펴보면 기본적인

구동방식에 대한 간략한 구현이고 블록킹 상황이나 기타 에러 발생시의

대처 루틴은 거의 빠져 있는 것 같더군요. 저도 처음 공부할때 이점 땜에

많이 헤멧는데요... 
아 아무튼 이렇게 어떻게 수신될 지 모르는 메시지를 처리하기 위해서는

메시지의 규격을 아래 말씀드린것 처럼 고정을 시켜놓는 것이 가장 편하다고

생각됩니다.

처음 몇바이트를 이후 전송된 메시지의 크기로 고정시켜 버리거나, 아니면

아예 메시지의 크기를 일괄 통일하는 방법(? 설마 이런 무식한 방법을?)


일단 이렇게 전송 수신 규약을 정하면 메시지가 어떻게 수신되든 간에 처리는

간단해 집니다. 
전송하는 측에서 보낸 여러개의 메시지가 어떤 식으로 뭉치거나 쪼개졌든 간에,

수신측은 메시지가 어떤 형태로 도착할 것인지를 알고 있으므로 그 형식에 맞게

대응하면 됩니다.


recv() 할때 Buffer의 크기와 받을 바이트 수를 최대 크기로 잡아도 상관은

없습니다. 문제는 recv()해서 받은 데이터가 전송측에 보낸 모든 데이터인지,

아니면 중간에 메시지가 나뉘어져 일부만 먼저 수신된 것인지 판단할 수

있어야 한다는 것입니다. 
참고로 소켓이 메시지를 받았을 때 그 소켓이 수신한 메시지를

모두 다 recv()해서 읽기 전 까지는 FD_READ 메시지가 계속 발생한다는 것입니다.

이 부분에 대한 코드는 전에 제가 써 놓은 글이 아래에 있으니 참고하세요. 
제 경험상, 그리고 어디서 읽은 문서의 내용상, UDP 소켓으로 주고받는 메시지는
TCP처럼 쪼개지거나 붙지는 않습니다.

UDP가 쪼개지거나 붙는다면, 대체로 UDP 통신량이 상대적으로 높은 Cafe9은 오동작을

자주 했겠죠. 
안녕하십니까 여러분...
아래의 코드를 유심히 봐주세요..

char pRecv[1024];
int iRecvLen;

if((iRecvLen = recv(sSocket, pRecv, 1024, 0)) != SOCKET_ERROR)
{

pRecv[iRecvLen] = NULL;
printf("%s\n", pRecv);

}

위의 명령중 뭐 잘못된 것이 있나요? 
0x00000000의 번지에 "written"할 수 없다는 메세지가
나옵니다.
물론 sSocket은 클라이언트의 연결 요청을 accept()함수로 받은 리턴 값입니다.
recv에서 저런 에러가 나오니 어쩔수가 없군요..
recv함수에 어떤 부작용이... (^^;)
아무튼 아시는분 답변 부탁 드려요..
이글 보는 모든 분들 좋은 하루 되세요... 
도착순서가 보장되지 않는 UDP 가 쪼개진다면..?
쓸수가 있을까요?

당연히 UDP는 안쪼개져야 정상이겠죠..
휭~

- Testors 
일단 코딩하신 소스로 테스트를 해보았으나.....
별이상 없이 잘 되더군요........
음냐.....
제 생각엔 accept()단계에서 잘못되어..소켓이 생성 안되었거나...
아니면 그 다음에 어떤 에러가 생겨서.....recv()가 제대로 동작하지 않아서
받은게 0바이트니까..
그래서 그렇게 된게 아닐까....
일단 완전한 소스를 봐야 알꺼 같네요...
게시판을 읽다보니
NODELAY 를 쓰면
팻킷을 10 바이트 씩 보낸다면 recv시
팻킷을 받을때 10바이트 이내로 받을수는
있지만 한번에 10바이트 이상 은 받지않는다는데.
결국 쪼개지는 경우는 있지만 합쳐서
들어오지는 않는다는 소리인가요..??
음..헷갈리는군.
하여튼 둘다처리를 그냥 해줘도
되지만 하여튼 이경우를
알고싶어 .질문합니다.
그럼. 
웬만해서는 그거 쓰지 마세요.
TCP_NODELAY는 Nagle algorithm을 안쓰기 때문에, 실질적인 레이턴시가 폭발적으로
증가한다는 소문이 있습니다. 
안녕하세요..^^;;; 여기 네트웍 관련 게시판이 있는줄도 모르고
어제는 윈도 게시판에다 윈속 관련글을 적어 버렸네엽..^^
뭐.. 다른분이 답을 해 주셨지만.. (여기 게시판에 답이 안올라오면
다시 거기다 적어버려야징..^^;;;;).. 답을 적어 주셨는데. 하여튼
그분 말씀대로 해서, 컴파일 링크까진 이상없이 넘어 갔습니다..

근데.. 근데..--;;;
The target platform of 'C:\windows\windock.dll' does not match the current
target platform.

이라는 경고가 나오면서 프로그램 실행이 안되는군요.--;;;
실행은 F5키나 하여튼. 여기서 실행하는것은 되지 않고 컴파일 링크가 끝난
실행파일을 실행하면 이상이 없습니다..(에러메시지가 뜨지 않는다는 말이죠..)
음.. 정확히 말하면.. 에러 메시지가 아니고 경고창이 뜨네요..
제가 알기론 winsock.dll은 16비트용으로 알고 있는데, 32비트용은 
windows\system\ws2_32.dll아닌가요? 왜 이런 에러메시지가 나오는건지..--;;

모 실행이야 되니까 별상관 없기도 한데.. 어쨋든 디버깅이 어려우니까요..
답변 알고계시거나 도움이 될만한 말씀이라도 한마디씩 던져주고 가주세엽..^^;;
그럼. 물러 갑니다.^^;; 좋은 하루 되시길..

ps - api소켓 프로그래밍에 대한 좋은 소스 알고 있거나 있으신분들은
자료실에 좀 올려 주세요..^^;;; udp소스는 약간 올라와 있는거 같던데
tcp에 관한건 없더군요.. 그럼.. 휙~~~~ 
안녕하세요? 학규입니다.

NT 에서 IO CompletionPort 사용시 입력을 받아들일때 ReadFile 을 사용하는지

아니면 WSARecv 를 사용하는지 궁금합니다. WinSock2 를 사용한다고 가정했을때

SDK 의 예제들을 보니 ReadFile 들로 되어있던데, 여기에서는 받을 량을 고정

해줘야 하게 되어있더군요.

부탁드리겠습니다

학규
neolith 
회사에서(kornet, 512kbps)에서 하이텔 접속하다보면...

페스워드가 짤려서 순서가 뒤바껴 입력될때가 종종 있더군요...

저는 체팅창을 열어두고... 로그인을 하기때문에... 오타는 분명 아니에요... ^^

-- 화수. 
chatting server를 짜고 있는데요.
client가 server에 접속할때 서버의 주소와 포트 , 그리고 이름을 쓰고
connect를 하는데요. server측에서 client들의 이름을 관리하려하는데
이름은 언제 client가 server에 날려야 하나요?
client,server는 CAysncSocket을 상속받은 class로 구현하고 있습니다.
그런데 문제는 client의 OnConnect에서 이름을 server에게 날리려고 하는데.
OnConnect는 server의 OnAccept보다 먼저 불리는 것 같은데요.
그렇다면 이름은 server에서 요구했을 때 날려줘야하나요?
질문이 복잡해졌는데요. 간단히 말해서 client에서 server에 자기 이름같은
정보를 날리는 것을 OnConnect에서 해도 되나요?

음.. 답변을 부탁드려용~~ ^^
줄거운 주말 되세요.

from 권형석 
하이텔 BBS 의 버그 이겠군요. TCP/IP 는 꽤나 신용있는 프로토콜 입니다.listening socket에서 server에 접속하는 사용자에 대해 접속에 대한 클래스(CClient
)를
만들어서 CClientList에 등록하는데요.
제가 궁금한 것은 접속하는 사용자마다 하나의 쓰레드를 생성시켜 그 쓰레드 안에서

무한 루프를 돌면 recv하는 것과 WSAAsyncSelect를 써서 recv하는 시점을 메시지로
처리 (FD_READ) 하는 것의 차이나 장단점은 무언가요?
전 현재 채팅 서버를 구현중인데 이부분이 궁금하네요.

답변부탁드리며..
fluorite
hithere@hitel.net 
overlapped i/o를 이용한 소켓에 대해 알고 싶습니다.
비졀씨를 뒤져보니 예제가 몇개 나오긴 하는데 도무지
모르겠군요.
개요부터..주욱 설명좀 해주셨으면 좋겠습니다. 
안녕하세요. 도움이 될만한 책을 발견해서 씁니다. 제목은 Network programming

for Windows 이고요 Jones 와 Ohlund 공저, Microsoft press 에서 나왔습니다.

책값은 49,000 원. 이 책을 예전에도 보긴 했었는데 관심사와 상관없는 내용이

너무 많은 것 같아서 대충 쓱 보기만 하고 안 샀더랬습니다. 하지만 요즘에

품게 되는 여러가지 궁금증에 대한 해답이 이 책에 거의 다 들어있더군요.

거두절미하고 Winsock 을 사용한 Overlapped I/O 랑 I/O Completion port 의

응용 (worker thread 를 이용한) 에 대한 실질적인 설명을 얻기 위해 며칠동안

웹도 뒤져보고, MSDN 의 샘플이나 문서들도 뒤져보고 했는데 몇가지 있는 내용
들은 Winsock 보다는 Named pipe 쪽에 치중되어 이해가 힘들었고, 실질적으로

쓸만한 예제를 준 경우는 거의 없었습니다만, 다행히 이 책에서 그 부분에 대한

대부분의 해답을 찾을 수 있었습니다. 책은 좀 두껍지만 정작 볼만한 부분은

Winsock 에 대한 기본기를 아는 사람이라면 한 10 페이지정도에 불과할겁니다

하지만 그 10 페이지에 정말 애타게 찾던 해답들이 들어있더군요.

아쉬운점이라면 예제가 부족하다는 점인데, 그나마 에코 서버라도 하나 있는걸

다행으로 여길 수 밖에 없는 상황이라. 이거 말고도 Server-sided programming 
어쩌고 하는 책도 있었는데, 아무래도 그 책보다는 이 책이 좀 더 피가 되고

살이 되는 내용이 보이더군요. 주머니가 넉넉해지면 그 책도 책장에 꽂아놓을

계획입니다만.

NT 로 수백 수천명이 접속가능한 서버를 만들기 위한 기본을 쌓으실 분은

꼭 보십쇼

학규
neolith

채팅 프로그램을 만들고 있습니다.
싱글 스레드 프로그램인데 읽혀진 버퍼를 처리하는 과정에서 또다시
FD_READ 이벤트가 발생하여 코드 포인트가 그쪽으로 옮겨지는 것 같습니다. --;
전체적 구조를 그려보면..

FD_READ:
1. 읽는다. ( while ( recv(..) > 0 ) )
2. 준비된 버퍼에 붙인다.(짤릴경우대비) append_buf(읽혀진버퍼);
3. 처리한다. (process_buf())
라고 할때 3번의 경우 시간을 많이 잡아먹거나 블록되는(? 예를 들어
모달 다이얼로그가 떳을 때 진행이 안되는것처럼) 경우 갑자기 1번으로
돌아갈 때가 있습니다. 이럴 때 대책이 없군요. --;

흠..어떻게 처리할 수 있을까요? 
음.. 이벤트가 중복해서 떨어지지는 않는데요??

수상하면 FD_READ 블럭 시작과 끝에다가 Log남겨보세요.

START 하나 END 하나 로그 남겨서 서로 짝이 안맞으면

중간에 끼어들기도 한다는 증거가 되겠죠?

근데 저는 그런일 일어난적이 한번도 없는데..

한번 테스트해보시길.. 
overlapped i/o 로 소켓 부분을 몽창 뜯어고치고 있는데 하다보니
이벤트 대기 최대 갯수(WSA_MAXIMUM_WAIT_EVENTS)가 64개로 선언
되어있네요.nt에서도 정말 64개가 최대인가요?
이런식이라면 서버 한대당 64명밖에 처리 못한단 얘긴데.아니 실제로는
63명이겠군요. 전에 소켓 갯수 얘기되었던것과도 관련이 있을거 같은데
이거 아시는 분 답변 부탁드립니다.
그냥 비동기 소켓으로 50개쯤은 열어봤는데 몇일 날려가며 뜯어고치는게
64개 이상을 서포트 못한다면 굳이 고칠 이유가... 
예 맞습니다.. WaitForMultipleObjects등의 함수들은 64개의 한계가 있습니다.
그렇기 때문에, 한개 스레드가 응답 대기를 할 수 있는 객체는 최대 64개입니다.
해결방법은, 접속하는 클라이이언트의 수/64개만큼의 스레드를 만들어 돌리는 것
입니다.

입출력 완료 포트는 NT에서 밖에 되질 않지만
서버 프로그래밍이라면 NT를 사용하실테고..
그렇다면 가장 이상적인 것은 중첩 입출력에 입출력 완료포트를
사용하는 거라고 책에 나와 있군요. 아직 해보진 않았습니다.
심지어 책의 저자도 해보지 않았다고 하는군요.
WaitForMultipleObjects()는 역시 64개의 핸들의 배열의 한계도
중첩완료포트의 GetQueuedCompletionStatus()를 사용하면 넘게도
가능하다는군요.
암튼 규모가 큰(유저 수천, 수만 혹은 그이상) 서버 애플리케이션의
설계로 그리고 NT에 멀티CPU를 쓴다면 더더욱 최적의 조건이라고 하는군요.
슬슬 I/O Completion Port의 정보 공유를 위해 분위기를.. 
completion i/o를 사용해서 대충 접속하고 끊고 받는건 되는거 같은데
send시 블럭이 걸려서 더 이상 보낼 수 없는 경우라던가...등등
소켓의 상태를 어떻게 알 수 있는지 궁금합니다.send스레드를 만들어서
다 보낼때까지 보내줘야하나요?
fd_write 상태가 되면 자동으로 알 수 있는 방법이나..그런건 없는지
알고 싶습니다. 
cpu점유율은 똑같군요.쩝.
accpet하는 부분을 스레드 쓰기 싫어서 accpet만 비동기 소켓
을 쓰고 나머진 complition i/o로 하려고 했는데 accept스레드 만들어서
돌려보니 똑같네요.
어차피 메시지 수신할 윈도우를 따로 만들면 내부적으론 스레드가
하나 더 생기는거니..흠.퍼포먼스가 나을 이유가 전혀 없겠단 생각..
wsaasync소켓에서 overlapped i/o로 overlapped i/o에서 completion i/o로..
음..사실 맨 처음엔 블럭킹 소켓을 썼었으니...
통째로 갈아엎는게 세번째군요.
이 짓 하다 시간 다 가겠네요.쩝쩝. 
winsock에서 소위 말하는 '유동 ip'로는 서버가 될수 없는지요?

유동 ip을 서버로 만들고 클라이언트를 접속시켰더니
접속이 안되더군요. 스타같은 경우에는 실게임으로 들어가면
메인서버에서 분리되어 나와 자기들끼리 연결이 이루어지는
걸루 알고 있는데, 아닌감?

어떻게 됐든, 유동 ip는 client가 addressing을 못하는 것 같아요!!!

???? 
물론 서버가 될 수 있져.
그치만 서버가 될때 어느 IP로 잡힐지 모르기때문에
항상 자신의 IP를 알려줘야합니다.
저의 경우 이를 막기위해서 메인서버랑 연결된 소켓의 어드레스를 인자로 넘겨서
클라이언트 서버를 메인서버에 연결된 소켓IP랑 항상 같게 생성합니다.
메인 서버에게는 이러한 IP정보들을 넘겨주고...
다른 클라이언트가 접속하려면 메인서버가 상대측의 IP를 넘겨줘야겠져.
위의 방식을 하이텔PPP, 두루넷에서 테스트해봤는데 둘다 유동아이피지만 아무런
문제가 없었습니다.
오재훈님께서 올려주신 답변 감사합니다.

아직 초보인지라 오재훈님께서 올리신 글중
궁금한 부분을 발췌해서 다시 올립니다.

[-------------------------------------------

물론 서버가 될 수 있져.
그치만 서버가 될때 어느 IP(1)로 잡힐지 모르기때문에
항상 자신의 IP(2)를 알려줘야합니다.
저의 경우 이를 막기위해서 메인서버랑 연결된 소켓의 어드레스(3)를 인자로 넘겨서
클라이언트 서버를 메인서버에 연결된 소켓IP랑 항상 같게 생성합니다(4).
메인 서버에게는 이러한 IP정보들을 넘겨주고...(5)
다른 클라이언트가 접속하려면 메인서버가 상대측의 IP를 넘겨줘야겠져.
위의 방식을 하이텔PPP, 두루넷에서 테스트해봤는데 둘다 유동아이피지만 아무런
문제가 없었습니다.

]----------------------------------------------

(1) 유동ip의 물리적인 작용?,
(2) 외부에서 볼때 ip가 자꾸 바뀌나요?
(3) accept할때 받아두었던 SOCKADDR 말씀하시는지?
(4) 어케하는 건지 구체적으로다가^^;;?
(5) 다시 넘겨주는 이유가 무엇인지?

저의 경우는 TCP/IP 기반입니다. (제대로 물어보는건지도 잘 모르겠네^^;; 에구에구)

바쁘시더라도 위의 질문에 답을 주시면 망극하여이다^^. 부탁드립니다..... 
───────────────────────────────────────
저도 네트웍 입문한지 한달도 채 안되어서 제가 아는 것이 확실한것인지는 모르지만
일단은 제가 아는 내용을 토대로 답변 드립니다.

(1) 유동ip의 물리적인 작용?,
- ip를 제공해주는 업체에서 고정적으로 할당하느냐 항상 접속할때마다
다르게 주느냐에 따라 고정, 유동IP가 되는 것이구요.
유동 ip라도 일단 한번 접속하면 ip는 변하지 않습니다.
(2) 외부에서 볼때 ip가 자꾸 바뀌나요?
- 유동 IP라면 매번 접속할때마다 바뀌겠져..
- 두루넷 같은 경우 컴퓨터를 켤때마다 바뀝니다.
끄기 전까진 바뀌지 않져..
(3) accept할때 받아두었던 SOCKADDR 말씀하시는지?
- 메인 서버에 접속한 소켓을 대상으로 GetSockName()해서 얻은 ip를 말합니다
- 그냥 자신의 ip를 gethostname()해서 얻은 ip를 사용해도 되지만
네트웍 카드가 2개 꽂혀있는 경우 내부내트웍 주소로 잡히더군요.
이를 막으려면 메인서버에 접속한 소켓의 ip를 getsockname()으로 얻어서
방장 서버 소켓을 생성할때 어드레스를 NULL로 주지말고 위에서 얻은
ip를 주면 됩니다.
(4) 어케하는 건지 구체적으로다가^^;;?
- 더 이상 구체적인것은 설명드리기 힘들고 나머지 세세한 부분은 관련서적을
참고하시기 바랍니다.
(5) 다시 넘겨주는 이유가 무엇인지?
- 다른 사람이 방장에게 접속하려면 방장의 ip를 알고 있어야하는데
이를 알고 있어야 하는 것은 메인 서버이므로 방장은 자신의 서버 ip를
메인 서버에게 알려줘야할 의무가 있고 메인 서버는 방장에게 접속하려는
다른 클라이언트에게 메인서버가 방장의 ip를 알려줘야할 의무가 있져.

p.S 그냥 짧은 기간동안 제가 경험한 것을 토대로 말씀드리는 것이라서
불합리하거나 잘못된 점이 있을수도 있습니다.
만일 틀리거나 개선해야할 사항이 있다면 지적해주시면 고맙겠습니다. 
유동 IP의 경우 단순히 PPP서비스를 사용하는 전화접속 사용자 뿐아니라
DHCP같은 서비스를 이용하는 회사에서도 유동 IP입니다.
DHCP서버는 IP를 중앙에서 관리해 주는 역할을 하는데
대기업 같은 대규모의 사무실에서는 DHCP를 쓰는 경우도 많더군요.
이런경우 사용자가 접속할때 마다 IP가 바뀌게 됩니다.
사용자가 IP를 관리할 필요가 없어지는 장점때문이죠.
일부 케이블 모뎀에서도 사용자를 DHCP로 관리한다고 하더군요.
겜방에서도 DHCP를 쓸 수 있겠군요.
IP관리가 중앙에서 된다는 장점은 PC를 깔때마다 일일이 셋팅하는 번거로움을
막아주니까요.
그럼.
__
이경만 
하이텔식 유동아이피는 proxy에 의해 정해지는 IP이기에, 하이텔로 인터넷을 접
속한 사용자의 IP와 외부에서의 그 사용자에 대한 IP가 서로 다르기에, "절대!
절대!" 서버가 될 수 없다고 알고 있습니다. (하긴..어떤 미친놈이 전화세 들여
가며 24시간 연결한 서버를 돌릴까요..?)

그런데..ADSL이나 두루넷같은 경우에서 언급되는 유동 IP는 proxy에 의해 구라치
는 IP가 아닌 실제 IP인가요? 

GetQueuedCompletionStatus()할때 보면
send가 완료된 시점이나 recv가 완료된 시점 모두 이 함수에 걸려드는데
이 경우에 잘 보냈단 소린지 잘 받았단 소린지 구분할 방법이 없나요?
바로 직전에 send를 했는 그 다음에 recv한 상태라면 이거 상당히 모호
하네요.
답변좀 부탁드립니다.
completion port쓰시는 분 없나요? 도무지 자료가 없어서 막막..
completion port & overlappped i/o로 소켓 프로그램을 짜고 있습니다.
wsarecv를 해두고 GetQue...()로 이벤트 발생시마다 처리하고 있는데
한참 돌리다 보면 WSARecv()에서 에러가 납니다.
에러코드를 찾아보니...

#define WSAENOBUFS 10055L
// An operation on a socket could not be performed because the system lacked
sufficient buffer space or because a queue was full.

이렇게 나와있군요.
그런데 recv란게 내부 큐에서 데이타만 뽑아오는게 아니던가요?
이 에러가 왜 나는지 이해를 못하겠네요.
아시는 분 답변좀 부탁드립니다. 

제가 알기론, IOCP는 recv,send,WSASend,WSARecv를 써서 송수신한건 처리 완료를
감지하지 못한다고 알고 있고, 실제로도 그렇습니다.

그런데.. 그걸로 IOCP가 된다고요?


지난 일주일간 소스를 홀딱 뒤집어엎고 뺑이를 친 끝에 compeltion port i/o
로 싹 바꿨습니다.
대충..스트레스 테스트라고 할건 없지만 테스트를 해본 결과...
윈도우 비동기소켓을 썼을때보다 메시지 처리 속도가 확실히 2배이상 빨
라졌습니다.
cpu부담도 엄청 줄고...이건 메시지 기반일때도 괜찮은 수준이었지만...
분산서버 모델이고 클라이언트 물리는 에이전트 쪽에 이 방식을 쓰고
있는데 일단 몇십개 정도의 클라이언트가 접속해서 50밀리세컨드 간격
으로 계속해서 메시지를 보낼때 디스플레이만 안하면 cpu점유율이 거의
0%에 가깝군요.

쩝.무대뽀로 구현하다보니 아직 불안한 부분이 좀 있긴 한데...
첨엔 안정성에서 상당히 문제가 많았는데 (일단 스레드가 두개씩이나 더 돌
다보니...) 손보다 보니 이전의 비동기보다도 오히려 안정성이 나은듯
하군요. 
예제도 적고 원서,핼프에서 이해 못할 말들도 많아서 꽤 헤맸는데
이제는 쓸 수 있을 정도로 구현된거 같습니다.
오히려 기존 방식을 쓰던 내부 서버가 다운되는 현상이...
아이고 앞으로 얼마나 더 뺑이를 쳐야할지..산넘어 산입니다. 
저는 IOCP를 수신처리에만 사용했습니다. 그러므로, GetQueud..함수를 쓰고 난
결과는 항상 수신에 관한 것이라 가정했습니다. 그래서, 송수신 두개를 모두 기
다리는 처리에 대한 구별을 하는 방법은 시도하지 않았습니다.

그.
러.
나..

직접 해본것은 아니지만, 제가 방법을 하나 제시하죠. 대신, 직접 해보시고, 잘
되는지 여부를 게시판에 올려주세요. 저도 궁금하군요..

BOOL GetQueuedCompletionStatus(
HANDLE CompletionPort, // the I/O completion port of interest
LPDWORD lpNumberOfBytesTransferred,
// to receive number of bytes 
// transferred during I/O
LPDWORD lpCompletionKey, // to receive file's completion key
LPOVERLAPPED *lpOverlapped, // to receive pointer to OVERLAPPED
// structure
DWORD dwMilliseconds // optional timeout value
);

IOCP의 그 유명한 API죠. 이 함수에서 디바이스 완료 이벤트를 기다리죠. 그런
데, 디바이스 완료를 구별하는 인자는.. lpCompletionKey,lpOverlapped 둘 뿐입
니다.

lpCompletionKey는 사용자가 정의한 아무 값이나 들어갈 수 있습니다. 소켓 번
호, 클라이언트 오브젝트 구조체의 포인터 등 아무거나죠. 그렇지만, 이것만 갖
고는 송신을 한건지, 수신을 한건지 찾기가 힘듭니다. 다른 예제를 보니까, 클라
이언트 구조체 객체를 위해 메모리를 할당할 때 약 1바이트 더 크게 잡은 다음, 
그 구조체를 메모리에 초기화하되, 초기화하는 위치를 반드시 '짝수 주소'로 만
든 다음, IOCP를 걸때 송신이면 그 객체의 짝수 주소를, 수신이면 홀수 주소를
넘기는 꽁수를 써서 이것을 구별한 것도 있더군요.

제가 시도해보라고 요청하는건 이건 아니고.. 확실히 되는 방법이지만, 프로그램
이 더러워지잖아요? 이제 얘기하려는 두번째 인자 lpOverlapped입니다.

만약 소켓 송수신을 ReadFile,WriteFile을 이용하는 경우, 마지막 인자로
OVERLAPPED 구조체의 포인터를 넘기죠. 우선, 송수신 각각을 위한 이 구조체 두
개를 마련해놓고(당연히 두개 구조체의 주소는 서로 다르겠죠.) 송수신을 걸 때
이 두개의 주소를 인자로 넘깁니다. 나중에 송수신 처리가 완료되면 GetQueued..
함수에서 lpOverlapped에서 둘 중 하나의 주소를 리턴할겁니다. 그렇게만 된다
면, 그 주소가 송신에 관한 OVERLAPPED인지, 수신에 관한 건지를 구별하는건 식
은죽 먹기죠.. 
함 해보세요. 그리고 결과를 보고해주시고요.

그럼 이만.. 
지난주에 내내 매달려서 대충 구현을 해놨는데 송수신 체크는
lpoverlapped뒤에다 플래그를 하나 둬서 그걸로 체크했구요.
송수신 완료..라기 보다도 send하고 나서 그 결과가 Getque...로
넘어오던데요.
wsasend를 사용했고 물론 overlapped로...
여튼 그런식으로 돌리고 있는데 일단 그 부분에 대해선 어느 정도
안정이 되었고 잘 돌아가네요.
샘플으 테스트해봐도 send다음에 send에 대한 결과 (10바이트 send해서
3바이트 보냈어졌다면 3바이트가 인자의 dword값에 포함되는 식)가
나오더군요. 
제가 알고 있는건 두루넷의 경우 입니다.
저도 두루넷관련 일을 할때 들은 내용이라서
직접 확인은 해보지 않았습니다.(케이블 모뎀을 사용하시는 분이 더 정확한 답을
주실수 있겠죠.)
두루넷 같은 경우 DHCP서버를 사용해서 유동 IP를 받게 됩니다.
이건 두루넷 케이블 모뎀을 켰을때 받아오는 것으로 컴을 켜고 끄는
것에 상관없이 케이블 모뎀을 켜고 끄는 것에 따라
IP가 부여되는것이죠. 그렇기 때문에 IP가 바뀌는 일이 생각 보다
자주 있지 않습니다. (그래서 두루넷 유저중에 불법 FTP싸이트를
운영하는 유저들도 많죠 ^^; 하지만 이건 케이블 구조상 바람직한 방법은
아니지만요.)
Proxy는 IP와는 실질적인 관계가 없습니다.(케이블 구조에선 캐쉬서버 역할만
해주죠. ISP까지의 속도가 ISP외부의 속도에 비해 엄청 빠르니까 중간에
캐쉬서버가 ISP내부에 있다면 당연히 효율이 높아지겠죠. 그래서 사용자에게
프락시를 쓰라고 하는 것이죠. 많은 케이블 ISP에서 말이죠.) 
그리고 실제 IP의 여부는 당연하게도 실제 IP입니다. 그렇지 않다면
인터넷 서비스의 많은 부분을 못쓰겠죠.
제가 알기로는 단말국마다 DHCP 서버가 있고 거기에 IP가 여러개 할당되어 있고
유저가 접속하면 DHCP서버에서 받아오는 것으로 알고 있습니다.
DHCP서버의 셋팅에 따라 유저에게 고정된 IP를 부여하는 방법도 있는것으로 알고
있습니다. 그렇게 하는지는 서비스 업체의 정책에 따라 다르겠네요.
일부러 서버를 만든지 못하게 하기위해 IP를 계속 바꿀 수도 있고요.
그럼 참고하시길.
__
이경만