Untitled

안녕하세여...

소켓 플밍을 하는데..
일단 연결은 잘 됐구여..
연결된 다음에 바로 FD_WRITE도 잘 받았습니다.
첫번째 FD_WRITE에서는 아무 일도 안하고 넘어가구요.
그런데 문제는 다음 FD_WRITE가 오질 않고...
계속 타임아웃만 나오는데...

무슨 문제일까요?

FD_WRITE와 모든 FD_시리즈는
다음 이벤트를 발생케 하는 함수가 있습니다.
즉,
FD_READ에 대해서는 Recv관련 함수(recv, recvfrom...)
등을, FD_WRITE는 Write관련 함수를 호출해야 합니다.
FD_WRITE가 발생했을때, 소켓에 데이타를 써주어야
다음 Event가 발생한다고 핼프에 나오는거 같네여.
아궁..
질문에 대한 대답이 맞는지 모를겠어요.
마소는 왜 새로운 기능을 추가하여 내 머리를 이렇게 아프게 할까여.
제 문제도 누가 풀어주세여..

안녕하세요...
어쩌면 저랑 똑같은 생각을 하셨는지 궁금하군요.... 헐...-__-;;
일단 저 같은 경우는... 일정량의 소켓들을 한 쓰레드에서 관리하구요
이런 쓰레드가 여럿 있는 방식을 쓸려고 합니다...
아직 테스트 중이죠...
소켓에 관련된 모든 데이터나 함수는 클래스로 묶어서
리슨 쓰레드가 입력을 감시... 연결되면 동적으로 객체를 생성해서
다음 쓰레드가 관리하는 소켓 리스트에 넣구요..

실제 입출력을 담당하는 이 쓰레드에서는 리스트를 하나씩
순회하면서 해당 소켓 객체에 대해 waitevent해서
입력이나 출력 사항이 있음 처리하는 거죠..
물론 각각의 소켓 객체는 입출력을 위한 큐를 갖는 구조입니다...
이제 제 질문인데요...
다음 fd_write가 발생하려면, send() 함수 부류를 불러야 된다고요?
만약 보낼 자료가 없음 어떡하죠?
fd_write의 경우 보낼 준비가 되어 있다는 것뿐인데..
보낼 준비는 되었지만, 보낼 데이터가 없다면, ????

서로 도움이 되었음 좋겠군요..그럼 이만.

안녕하세요..

해봤는데.... 가긴 가는군요.
그런 다음에는.... 다시 FD_WRITE가 오질 않구요....에궁..
WSAEWOULDBLOCK이 나서 에러로 끝나야 다시 나오는 거 같은데..
어떻게 해야 날까요?? -_____________________-;;

안녕하세요..
저도 비슷한 방향으로 생각을 하다가..
효율이 떨어질거 같아서 우물쭈물 하고 있습니다.
일단 FD_WRITE 에 대한 저의 생각을 말씀 드리죠.
FD_WRITE의 이벤트가 발생하려면 EventSelect를 해야하구요.
이건 데이타를 보내려고 할때 설정하게 되는 거죠.
소켓이란 양 끝단이 존재하여 상대방이 Recv를 하여야
계속하여 Send를 할수 있습니다. 버퍼한계땜이죠.
소켓버퍼는 정상적인이상(상대방이 정상이라면 계속
데이타를 읽겠죠?)FD_WRITE 가 계속 발생하겠죠.
이런 특성때문에, 하나의 소켓에 대해서
FD_READ와 FD_CLOSE는 항상 설정되어 있어야 하고,
FD_WRITE는 보낼 데이타가 있을때만 한번설정하는겁니다.
결론적으로,
FD_WRITE를 더 받고 싶다면,

WSASelectEvent를 FD_WRITE로 설정하여야 하고,
더보낼 데이타가 없다면 기본설정(FD_READ, FD_CLOSE)으로
해놓아야 하죠.

이제 궁금한점을 물어볼께요.
저는 여태껏 WSAAsyncSelect를 사용하여 메세지 처리를 해
왔습니다. 그러다 멀티 쓰레드를 고려하여 라이브러리를
재구성하려 하여 WSAEventSelect구조로 바꾸려는 중에..
WSAEventSelect는 (아궁,, 위에 WSASelectEvent는 틀린거네여)
이벤트 발생시 어느 소켓에서 발생한 이벤트인지 알수 없다는
문제가 생긴겁니다.
즉 리슨소켓에서 1000개의 Child terminal소켓을 생성하여
관리 하는 경우의 Select시 FD_READ? 발생한다면
1000개의 소켓을 전부 EnumNetworkEvent하여 조사해야 하잖아여?
어떤 애가 이벤트를 발생시켰는지에 대해서요.

물론 쓰레드의 수가 소켓수와 같다면 문제 없지만.
쓰레드 하나당 소켓 20개 정도에 대응시켜도 마찬가지로
최대 20번의 EnumNetworkEvent의 호출은 불가하다는 얘기죠.
피
이건 메세지 방식에 비해 너무 불합리한 방법이라고 생각이
들어서요.
깔끔한 소켓2방식의 멀티쓰레드 클래스를 생성하려다
오버헤드가 생각보다 크군요.
최인호님은 어떻게 해결하려는 생각이신지 궁금합니다.
그럼 조언 부탁합니다.

안녕하세요....

먼저 제가 생각하는 방법에 대해 설명을 드리죠.

흠.. 제가 생각하는 방법은...

WSAEventSelect(s1, event1, FD_~~~~~);
WSAEventSelect(s2, event2, FD_~~~~~);

~~
WSAEventSelect(sn, eventn, FD_~~~~~);

위의 문장이 가능하다는 가정이 되어야 합니다.

WSAEventSelect()의 경우 한 소켓에 대해 두개의 이벤트로

다른 네트워크 이벤트를 감시하는 것이 불가능합니다.
하지만, 다른 소켓인 경우는 당연히~(?) 상관없다고 생각....
아직 테스트를 해보지 못했서 뭐라 말씀 드릴 수는 없지만..

그럼 본격적으로 설명을 드리죠.
제가 생각하는 것은 하나의 리슨 쓰레드와 다수의 작업 처리
쓰레드로 구성됩니다.

리슨 쓰레드에서는 연결이 허용되었을 때, 소켓 객체를 동적으로
생성합니다. 소켓 객체에는 소켓디스크립터, 이벤트핸들, 송신 큐, 수신 큐,
기타 멤버 변수와 WSAWaitMultipleEventSelect()함수를 호출하는 멤버 함수와
기타 멤버 함수들을 갖습니다.
객체를 생성하면, 각 작업 쓰레드 중에 하나를 선택하게 되고, 이 작업 쓰레드가
관리하는 소켓 클래스 포인터 리스트에 소켓 객체의 포인터를 추가합니다.
이렇게 리슨 쓰레드의 작업은 끝이구요..

이제 각 작업 스레드를 보면..
리스트를 순회하면서 처리하게 되어있습니다.
리스트의 헤드노드부터 뒤져서 해당 노드의 소켓 객체 포인터를 찾아,
소켓 객체의 WaitEvent 함수를 부릅니다. 여기에서 모든 소켓 작업이
이루어 집니다. 송신할 것이 있으면, 송신 큐에만 넣어주면, fd_write가 발생했을 때
,
송신 큐를 뒤져서 보낼 메시지가 존재하면 송신하고, 받은 메시지는 수신 큐에 넣어
주고
윈도우에 윈도메시지를 보내면, 메인어플리케이션 쓰레드가 읽어오는 방법이죠.

즉, 하나의 WSAEventSelect() 함수는 하나의 소켓과만 매치되는 것이죠.
이제 간단히 제 설명을 마쳤는데요...

이제 다시 제가 질문할 차례군요... ^^;
지금 문제가 되는 것이.... 클라이언트의 경우, 연결이 됨과 동시에
fd_write가 발생하는 데, 지금으로서는 송신 큐에 보낼 메시지가 없으므로,
아무런 처리도 안하고 넘어갑니다. 그런 다음 송신 큐에 메시지를 넣어 줘도,
fd_write가 발생하지 않기 때문에 송신이 안된다는 것이죠...-__-;;
말씀듣고, 메시지가 없어도 WSASend를 호출해서 0바이트를 송신했는데도,
발생하지 않더군요...-_-''
만약, WSAEventSelect로 fd_write를 뺐다가 다시 넣으면, fd_write가 발생할 까요?
흠....

또 모르는 것이 있음 질문하겠습니다...
그럼 수고하세요..

일단 답변부터..
어떤 소켓에 데이타를 보내려 할때 큐에다가 데이타를 넣는다고
했죠.. 이때 그 소켓에 WSAEventSelect(sx, eventx, FD_WRITE);
로 설정을 동시에 해줍니다.
그럼.. 이벤트가 발생하면서 FD_WRITE가 발생하죠.
즉 하나의 WSAEventSelect()에 대해 한번의 FD_WRITE가 발생합니다.
저도 이벤트에 대해서는 시도 하고 있는중이라..
하지만 인호님의 계획에서 이렇게 한다면 될거 같네여.

질문 입니다.
저도 현재 인호님의 생각대로 기획하려고 했습니다.
문제점이 있더군요.
하나의 쓰레드는 복수 개의 이벤트를 동시에 기다릴수 있습니다.
현재 다큐먼트에 나온 한계로는 64개로 설정되어 있습니다.
즉 현재 win32에서 API의 최대 64개의 이벤트를 기다릴수 있습니다

(WaitForMultipleObjects()참조.. WSAWaitFor... 은 Win32 API를
Wrapping시킨걸 거든요.)
그렇다면 쓰레드당 64개의 이벤트개, 180개의 프로세스당 쓰레드
한계를 고려 한다면... 서버의 통신라이브러리로 너무 많은 리소스
를 사용한다는 계산입니다.
제 생각에는 10000개 이상의 접속을 받는 서버로(이론적인면)
설계되어야 하고, 그러려먼 소켓 통신 모듈에서만 너무 많은 쓰레드를
사용하는군요.. 혹시 이러한 문제를 고려했는지 궁금하고..
다른 해결책이 없나 해서요..
프로세스당 180개의 쓰레드밖에 생성할수 없다는건
AfxBeginThread()함수를 루프를 돌려서 생성해 봤습니다.
이것에 대한 해결책으로
WSAEventSelect(s1, event1, FD_READ);
WSAEventSelect(s2, event1, FD_READ);
...

...
등으로 여러 소켓이 하나의 이벤트를 공유하는 겁니다.
그러면 소켓여러개를 쓰레드 하나가 관리 할수 있겠더군요.
근데 이벤트가 발생하면 어느 소켓에서 발생했는지는 모르겠더군요.
소켓을 순서대로 검색하는 방법 외에는요.

답변 기다릴께요..

인호님의 아이디어는 제가 고려하지 못한 부분인데요..
좋은 해결책인거 같습니다.
Looping방식에 의한 일종의 polling개념인데..
그렇다면 제가 생각한 문제를 해결할수 있는 방법인데요..
하지만 2가지 오버헤드가 있겠군요.
1번째로 소켓을 특정시간 간격으로 polling하기 때문에
일이 없을 경우 죽어 있어야 할 Thread가 계속적으로 살아
나게 됩니다. Event가 발생하지 않아도 말이죠.
이것은 WaitForMultipleevents()의 시간을 짧게 할수록
크게 두드러지는 오버헤드입니다.
2번째로 마찬가지 개념때문에 어떤 소켓에 읽을 데이타가
있게 될경우, Looping소켓이 많아지면 데이타가 발생하는
순간 읽는 것이 아니라 Polling타이밍때 읽어오므로
뒤늦게 소켓에서 데이타를 읽어오게 되는겁니다.
WaitForMultipleEvent()의 시간을 길게 할수록

두드러 지는 오버헤드 이죠..
이문제는 100밀리세컨드의 Delay만 발생하더라도
소켓의 성능에는 큰 영향을 미칩니다.
소켓 버퍼가 4096일 경우, 초당 40K 이상의 성능은 절대로
안나오니까요.. 즉 상대방 소켓 버킷에서 데이타를 보내려
해도 서버의 이러한 루핑개념때문에 생긴 Read Delay는
상대방 소켓버킷에서는 WouldBlock의 Error를 내고
더이상 Send를 할수 없게 만들거든요.

두번째 문제점은 라이브러리로서는 치명적인 결함이 될거
같습니다.
결국 Event Driven에 위배되는 폴링 방식은 여러 결함이
생깁니다..

최대한의 오버헤드축소는

WaitForMultipleEvents()함수에서 Event오브젝트갯수를
최대로 크게 하는 방법밖에는 없습니다..
즉 10개이상 묶어서 여러 오브젝트를 동시에 기다리는..

흠.. 저의 즉흥적인-혹시 제가 생각치 못한 다른 해결책이
있을수 있으니까요-생각 이었습니다.

FD_READ는 읽어야 할 데이터가 수신될때마다 통보되지만 FD_WRITE는 그렇지
않습니다.

이거 전에도 주의하라고 글 쓴 적이 있는것 같은데... FD_WRITE 메시지가 통보되는
시점은 소켓이 처음 만들어져서 송신이 가능해 진 시점에 한번, 그리고 메시지 전송
도중 블록킹이 걸려 송신이 중단되었을 경우, 잠시후 소켓의 블록킹이 풀려 메시지
전송이 가능해 질때 한번 통보됩니다.

이것 잘못 이해하시고 프로그램 하시면 잘 전송되다 갑자기 전송이 안되는 등
이상한 현상이 발생할 겁니다. 사실 블록킹 상황이라는 것은 LAN환경 아래에서
테스트 할 때에는 거의 발생하지 않기 때문에 나중에 실제로 서비스 할때 이문제가
발생하여 낭패를 보는 경우가 있을 수 있습니다.

아.. 제가 잘못사용하고 있었군요.
그래도 별문제 없이 사용했거든요.
보내려고 할때마다 재 설정을 해서 사용했으니 문제가
없었군요.. 고맙습니다..
수정하려면 생각좀 해봐야 겠군요.. 허

안녕하세요...

음.. 요식님 답변 잘 읽었습니다.
저도 사실 그러한 오버헤드에 대해 걱정을 했습니다.
그리고, waittime을 잘 조절하면 상당히 가능성이 있으리라 생각했는데..
흠.. 두번째 오버헤드의 문제를 생각하지 못했군요..
리스트에 소켓이 많은 경우, 이벤트 발생후, 폴링되는 시점까지...
대기 시간이 길므로.... 상대편의 wouldblock....
허허... 난감하네요..
그렇담, 이벤트드리븐 방식으로 하기가 난감해지는데....-_-;;
윈도우에 메시지를 보내는 방식보다 빠르리란 예상때문에
이 방식을 고려하게 되었는데, 문제가 많군요...
흠냐.. 뭔가 방법이 있을법도 한데..
이런 문제를 해결할 방법이 없다면, 이벤트드리븐 방식의 필요성이
거의 없군요... 에구.. 뭐 데몬 프로그램을 만들 것두 아니구.

요식님 같이 고민 좀 해보죠... ^^;
가능하면 이 방법을 고수하고 싶긴 하지만..
안된다면... 결국.... 구조 자체를 바꾸면..
애매하다 애매해.... 그럼 수고하세요..

아까 깜빡했었는데요..

아래 글의 소켓 버퍼가 4096이라는 것은...
네트워크 카드의 버퍼를 말씀하신 건가요?
아니면 프로그램상에서 잡은 버퍼 사이즈를 말씀하시는 건가요?
후자쪽인 거 같은데...
그리고 40k의 성능이라는 것도...
서버쪽입니까 아니면 클라이언트쪽입니까?
궁금하군요... ^^;

안녕하세요..

생각을 해 봤는데....
결국은, 한 쓰레드에서 처리할 최대 클라이언트 수를 정한 뒤,
(예를 들면, 320명... 이렇게요..)
64개씩의 이벤트를 갖는 이벤트 풀(event pool)을 만들어서 하는 수가
최선일 거 같습니다.
위의 예의 경우는 5개의 이벤트 풀을 갖겠죠.
쓰레드에서는 한번에 한 이벤트 풀씩 waitevent하고..
다음 이벤트 풀로 넘어가고....
64개 이상을 할 수 없다면, 달리 방법이 없지 않을까요?
64개의 클라이언트 미만이면 정상적인 속도가 나겠고..
이 경우는 클라이언트 수가 많으면 느려지겠군요.
그래도 전의 제 생각처럼 320명을 순차적으로 기다리는 것보다야 낫겠죠.
결국 5번의 WAITEVENT를 해야 되는 거군요.

그렇담 추가로, 이벤트 풀의 이벤트를 선택해 주는 작업과,
이벤트가 발생했을 경우, 해당 소켓을 찾아주는 방법이 필요하군요...-_-;

흠.. 그리고 하나 질문을 하겠는데요..
어짜피 이 부분을 루프로 돌리니까 스레드가 계속 작업하는 것이 아닙니까?
wait하는 동안 들어온 이벤트가 없다면 sleep하는 건가요?
일부러 Sleep(sleeptime) 해 줄 필요는 없겠지요?

생각하면 할 수록 생각이 꼬이는 군요.

제 생각에 대해 말씀해 주세요,.,

인호님이 말씀하신 방법대로 한다고 했을경우
최대 5개의 event pool에 대해 폴링을 해주어야
하고 그럴경우 WaitForMultipleEvents(s1, event1, time);
에서 time값이 중요한 파라미터로 작용합니다.
여기서 time값은 이벤트가 발생하기 전까지 얼마만큼 쓰레드
를 Sleep시킬수 있냐를 설정하는 것이니만큼..
이 값을 작게 하면 자주 쓰레드가 깨어나서
CPU time을 잡아먹게 됩니다. 1번째 오버헤드이죠.
그렇다구 이 값을 크게 하면..
time * 5 만큼의 시간을 소켓에서 데이타를 읽지 못하
는 경우가 생기는 거죠. 2번째의 오버헤드입니다.

버퍼크기가 4096이라고 한건 예를 들어서이거든요.
숫자에대해 정확히 기억을 못해서 대충 적은겁니다.
어쨌든 조정을 잘하셔야 할거 같습니다. 버퍼가 한정된건

사실이니깐요.

제가 생각하는 거에 문제점이 있을수 있으니
감안하시구요.. 도큐먼트를 완벽히 읽고 파악한게 아니라
개인적인 경험에서 분석한것이니 만큼이요..

그럼 도움이 되셨기를..
아궁 저는 메세지 방식으로 돌아서야 겠어여..
대신 메인쓰레드에 영향을 안받는 방안을 생각해 봐야 겠습니다.
읽기 쓰기만을 전담하는 쓰레드를 만드는 방안이죠.. 메세지방식으로..
그럼..

흠... 안녕하세요.

요식님이 메시지 방식으로 돌아선다니...아쉽네요..
쩝... 하지만, 전 그대로 이벤트방식으로 갈까 합니다.
어짜피 메시지큐에서 내용을 읽어와서 메시지를 처리하는
오버헤드나 5번의 폴링을 하는 경우나 비슷하리라 생각됩니다.
이는 아무튼 제 개인적인 생각이고요.

흠... 4096바이트의 버퍼라...
저는 최대 10k의 버퍼를 잡아두려고 하는데..
최대 메세지가 10k를 넘지 않으니까요.
그리고 4096바이트의 버퍼를 가진 경우, 초당 40k 이상의 속도가
안나온다고 하셨는데..
초당 40k라면, E1급일텐데..
이 정도 속도면 괜찮은 거 아닌가요? ^^:

하여간 타임을 잘 조정해서 최대의 효율을 내도록 노력해 보죠.
그럼 이만.

메시지 쪼개짐과 합침에 관한 내용은 아래 기현님 말씀 그대로입니다.
그리고 동시수신이 안된다는 것... 클라이언트 1개당 소켓이 클라이언트 소켓 1개,
서버측 소켓 1개가 할당된다면 동시수신이라는 개념이 없을것 같은데요... 어차피
클라이언트마다 독립된 소켓을 사용하니까요... 제 생각에는 send() 도중에 블록킹
이 걸려서 보낼 데이터를 못보내었을 경우 전송 메시지 큐에 넣은 후, FD_WRITE가
수신되었을때 전송 메시지 큐에 남아있는 데이터를 먼저 보내고 그다음 데이터를
보내야 하는데 이 처리를 제대로 하지 않아 데이터가 유실되는 것 아닐까 합니다.
ex)

게임은 계속 진행되고, 이벤트는 계속 발생하므로 메시지를 전송해야 하는 시점은
계속적으로 발생합니다. 그러나 네트웍 사정이라는 것이 항상 메시지를 전송할 수
있는 것이 아니므로... 처음에는 정상적으로 프로세싱을 하면서 메시지를
전송합니다. 그러다 소켓이 블록킹이 걸립니다. 이젠 더이상 메시지를 보낼 수 없습
니다. 그러나 네트웍이 블록되었다고 게임 진행도 멈출 순 없으므로 게임은 계속
진행되고 메시지를 보낼 경우도 계속 발생하죠. 이럴때 보내야 할 메시지는
순서대로 전송 메시지 큐에 저장되어야 합니다. 만약 전송 메시지 큐에 조금이라도

보낼 데이터가 남아있다면 소켓이 블록킹 상황이 아니더라도 전송 메시지 큐에 넣어
야 합니다(이점이 중요) 그러다가 FD_WRITE가 오면 전송 메시지 큐에 있는 데이터를
순서대로 전송합니다. 그런데 큐에 데이터가 너무 많이 밀려 있다면 큐의 데이터를
보내다가 또 블록킹이 걸릴 수 있겠죠. 그럼 보내다 남은 데이터를 또 순서에 맞게
보존해 놓아야 합니다. 대략 이런 식의 작동구조가 온전히 구현 된다면 소켓의
연결, 전송, 블록킹 상황에 대한 대처는 다 되는 것이라 볼 수 있습니다.
한가지 더 큐가 가득차면 그 소켓은 더이상 복구가 불가능하므로 접속을 끊어야
겠죠.

이 과정을 클래스로 구현하여 사용하는 것이 가장 편한것 같더군요.

안녕하세요?

갑자기 머그에 관심이 생겨서
winsock을 가지고 돌려보니
서버나 클라이언트나 큰 어려움은 없네요.

근데 밑에 광현님(맞나?) 설명을 보니 FD_WRITE가
계속 호출되지 않고 특정한 때만 호출이
된다고 하셔서 해보니 정말 그렇더군요.

send()를 계속하다가 블럭킹(맞는용언가?) 이
생긴걸 어떻게 알수 있나요?

FD_WRITE가 클라이언트가 컨넥트되고 한번호출된후
쓰기 가능함을 알고 계속 보내다가 블럭킹이

걸리면 쓰기 금지해서 send()를 안할려고 하는데
블럭킹이 언제 걸렸다는걸 알수가 없네요.
랜을 사용하니 블럭킹 걸릴일이 별로 없는거 같아서..

일반 게임만 만들다 윈도메시지에 의존하는 프로그램을
구현하자니 약간 헷갈리는 군여.

send()보내다 블럭킹걸린거 알수 있는방법을
알려주세요.
그럼 감사..

send()를 하면 send()함수에서 실제로 보낸 바이트 수와 만약 에러가 발생했다면
SOCKET_ERROR가 리턴됩니다. 에러의 종류를 알려면 WSAgetLastError() 를 실행해서
에러값을 얻어오며 이 값이 BLOCK이면 블록킹으로 인해 전송이 중간에 중단되었음을
의미하는 것이고 다른 에러라면 대부분의 경우 소켓을 끊어버려야 합니다.
즉 소켓에러라고 해도 블록킹 에러라면 소켓을 끊을 필요 없이 다음 FD_WRITE가
수신될때까지 전송을 기다리면 되는 겁니다.
함수의 스펠링과 리턴값은 헬프를 찾아보세요 제가 쓴것은 정확하지가 않아요.