비동기 connect 시...
안녕하세요.
저 같은경우 비동기 커넥트시
connect 후 커넥트가 진행중이면 read 셋,write 셋, except 셋 에다
소켓을 셋한후 select 후 write 셋을 검사하여 write 셋에 소켓이
셋되있으면 접속된걸로 간주하고 except 셋에 소켓이 셋 되잇으면
실패한걸로 간주합니다.
여기서 궁금한거는 최초의 select 에서 아무런 이벤트(접속성공,실패)를
감지하지 못했을경우 다시 감지를 하기 위해서 write 셋과 except 셋에
다시 소켓을 셋해야 하는지 궁금합니다. 당연히 그래야 할것 같은데
제가 테스트(윈도우에서)할때는 최초의 select 에서 접속성공 또는 실패
를 알수 있어서 그런가보다 하고(최초의 select에서 접속성공실패여부 확인)
알고 있었습니다.
리눅스(SuSE) 에서 상황을 접속실패로 해놓고(접속할서버를닫아놓고) 테스트
해보면 최초의 select 호출후 read,write,except 의 각 fd_set 의 변화를
살펴봤더니 read 셋과 write 셋에 소켓이 셋 되있었습니다
(connect 호출후 read,write,except 에 소켓을 셋해두었습니다)
상황이 접속 실패다 보니 except 에 소켓이 셋 되길 바라고 있었지만
황당하게도 write 셋 말고도 read 셋까지 소켓이 셋되있어서 머리에서
쥐가날 지경입니다. 혹시 이런 현상을 겪으신분 계시는지 궁금합니다.
man 페이지를 살펴보면
------------------
The socket is non-blocking and the connection cannot be completed
immediately. It is possible to select(2)
or poll(2) for completion by selecting the socket for
writing. After select indicates writability, use get?
sockopt(2) to read the SO_ERROR option at level
SOL_SOCKET to determine whether connect completed success?
fully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is
one of the usual error codes listed here, explaining
the reason for the failure).
-----------------------
위와같이 소켓이 write able( 셀렉트 호출이후 write set 에 셋되었을경우 )
되었을경우
getsockopt 로 옵션을 SO_ERROR 로 줘서 결과를 얻어 접속성공이냐 실패냐를
알아보라고 했는데 성공해야 할경우나 실패햐애 할 경우에나 항상 결과는
성공으로 나옵니다.
코드는
int ret = getsockopt( sock, SOL_SOCKET, SO_ERROR, &error, &error_size );
이며 error 값과 ret 값이 0 이 아닐경우를 접속실패로 간주했습니다.
사실상 getsockopt 를 이용한 비동기 커넥션 성공여부 판단은 포기하고 있는
실정이지만 혹시 이에대해 좀 아시는분 참고말씀 부탁 드립니다.
아래글에도 이와비슷한 글을 올렸는데 어느분께서
접속성공 실패 여부를 떠나서 일단 무조건 select 이후 write 셋에는
소켓이 셋되있다고 하시더군요(UNP 에 나온다고말씀)
만약 접속이 실패든 성공이든 무조건 write 셋에 걸린다면 select 이후
이벤트체크에서 걸린 소켓(즉 write 셋에 걸려버린소켓)은 어떻게
접속이 성공했는지 실패했는지 알수가 있는지 궁금합니다.
말이 길었는데 요약하자면
보통 select 를 이용한 비동기 소켓 커넥션은 어떤식으로 이루어지는지와
최초의 select 호출이후 아무런 이벤트를 감지하지 못햇을경우
다시 read,write,except 셋에 접속성공 여부를 감지할 소켓을 셋하고
감지할때까지 이와같은일을 반복하는지..
또 저같은경우 접속실패 상황에서 왜 read 와 write 셋이 셋되서
나오는지...
조그만 참고말씀이라도 귀담아 듣겠습니다.
감기조심하시고 읽어주셔서 감사합니다.
다시 말씀드립니다. UNP 보시면 비동기 connect 처리법이 나와있습
다시 말씀드립니다. UNP 보시면 비동기 connect 처리법이 나와있습니다. 자세히 읽어보시면 궁금한 것이 해결되리라 생각합니다. 꼭 책을 먼저 읽어보시기를 권장합니다.
UNIX에서는 Winsock과 다르다고 하네요UNIX에서는 연결이 성
UNIX에서는 Winsock과 다르다고 하네요
UNIX에서는 연결이 성공했는지의 여부를 알리기 위해서
읽기와 쓰기가 모두 가능하게 만듭니다.
커널 구현이 그런걸 ... 왜 그렇냐고 따지기 보다 ㅎㅎ 그냥 쓰셔야 겠죠
일단 select() 리턴후
readable도 아니고 writable도 아니라면
소켓은 연결이 되어 있는 상태로 판단가능하구요
그다음엔
getpeername()을 호출해서 정상리턴이면 연결된 상태입니다.
만약 getpeername()이 ENOTCONN을 리턴하면 연결안된상태이구요.
getsockopt() 호출해줘서 아직 가지고 오지 않은 에러코드를 가지고 오신후에 error코드를 살펴보시면 됩니다.
만약 getsockopt() 자체가 실패하면
errno가 getsockopt()호출에 대한 실패를 저장하겠죠?(맞나 ㅡ.ㅡ, 불확실..)
제가 말씀 드린 부분을 isconnected() 함수로 만들어서
사용하시면 될것 같네요
이상한점 발견..
일단 저의 상황에 대해 말씀드리자면
전 커넥트 타임 아웃 함수를 만드는것이 아닙니다.
UNP 책이 없어 게시판뒤져서 다른분들이 예제올리신거 봤는데
비동기 커넥트 타임아웃 함수더군요.
저는 반응시간에 민감한 (중간에 거의 멈춤없이 계속돌아가는)
서버프로그램을 짜고있고 다른 서버와의 연동을 위해 타 서버로
접속하는 클라이언트 모듈을 짜고 있습니다. 여기서 타 서버로 접속시
블럭 또는 시간지연이 안되게 하기 위해 비동기 connect 를 이용하며
이 클라이언트모듈을 모든 서버 소켓및 차일드소켓과 같이 관리 합니다.
일단 비동기 connect 에 대한 방법은 많이 파악하고 있었는데 계속 이상한
오동작을 해 많이 혼란스러웠던것 같습니다. 지금 오동작을 하는 상황을 판단
했는데 다음과 같습니다.
접속하는 서버가 꺼져있는상황에서.
(이 서버프로그램은 타서버로 접속하는 클라이언트 소켓만 관리 하는
것이 아니라 차일드 소켓들도 관리합니다. 그래서 따로 접속용 select 를
만들어서 돌리지 않으며 테스트 할때는 클라이언트 소켓만 관리해서
테스트 했습니다)
1. 목적 서버가 로칼호스트일경우(즉 같은 컴퓨터) ex)127.0.0.1
select 를 통과하면 read 셋과 write 셋이 동시에 셋 됩니다.(select 리턴값 2 )
2. 목적 서버가 타 호스트일경우(remote) ex)192.168.1.1
select 를 통과하면 아무 fd_set 도 셋 되지 않습니다.
그래서 접속실패 경우 어떤 상황이 정상인것으로 판단 해야 하는것인가
에 대한 고민을 많이 하다 위 1번상황(목적 서버 꺼짐, 목적서버 로칼호스트)
을 고려하여 다음과 같이 했습니다
일단 read set 체크 루틴은 데이타가 오거나 접속이 끊긴것을 처리해야
하는 루틴이므로 비동기 접속에 대한 실패여부를 판단하는 루틴을
넣는것은 안좋은것 같아 어차피 접속이 안됬으면 recv 에서 접속 끊긴것
으로 판단하여 소켓을 닫는 루틴이 호출될것이므로 그냥 둠.
read set 이 셋됨과 동시에 write set 도 셋 되므로 별도의 처리가 필요하
다고 판단.
write set 이벤트 발생처리 루틴은
write set 될때 접속요청중인 소켓이였으면(따로 소켓클래스에 셋팅해둠)
접속성공처리를 하는 루틴임.
하지만 접속 실패의 경우도 write set 이 발생하므로 어떻게 할까 고민하다
위 write set 이벤트를 처리하기전 read set 에서 소켓을 닫으므로
소켓이 닫혀 있으면 continue 처리.
이렇게 하였습니다. 일단 이렇게 하니 문제없이 잘 동작은 하는데
마지마으로 궁금한점!
왜 접속 실패하엿을경우 exception set 은 발생하지 않을까??
exception set 은 실제로 거의 쓰이지 않는 set 일까 하는점입니다..
긴글 읽어주셔서 감사합니다. ^^ 참고 말씀 기달리겠습니다.
Re: 이상한점 발견..
모르고 로그인을 안하고 글을 썼습니다. ^^;;
UNP 에서는 넌블러킹 소켓으로 connect 를 했을 때 생기는 문제점
UNP 에서는 넌블러킹 소켓으로 connect 를 했을 때 생기는 문제점과 connect 후에 처리해야 할 일 등을 기술하고 있습니다. 그 예제 코드만을 가지고서 말씀하시지 마시고, 먼저 읽어보시는 것이 도움이 됩니다.
UNP 구현과 달리 select 를 중앙집중식으로 하시는가 봅니다. UNP 구현의 select 부터를 작성하시는 코드에 적절히 배치하면 될 것이구요.
그리고, 1. 번의 경우에 어떻게 처리해야 하는지 UNP에 얘기되어 있고, 2. 번의 경우 select 에 시간을 주어서 대기했다면 어떻게든 (접속되든 안되든) 해당 fd_set 을 (최소한 writable) 세팅해줍니다. 만약 기다리지 않게 하고 조사하거나 시간이 만료되었다면, 접속성공/실패 여부를 모르고 시간만료에 해당하는 0을 리턴하고 아무런 fd_set 을 설정하지않고 리턴될 것입니다. 중앙에서 select 한다면 판단이 애매해질 수 있겠습니다. 다른 fd와 섞여서 select의 리턴값만으로는 넌블러팅 connect의 시간만료인지를 알 수 없을테니, 해당 fd 의 타임아웃 시간인지를 판단하는 코드가 추가되고 시간만료이면 fd_set 세팅이 없을 때라는 조건이 있어야 실패로 확인되겠습니다.
정 책이 없다면... 서점에서라도 보실 수 있지 않습니까. 해당하는 페이지가 몇페이지 안되니까요. 보기만해도 좋은 결론에 도달할 수 있다고 생각합니다.
UNP 를 먼저 꼭 구해서 읽어보시면 좋겠습니다. 먼저 경험한 사람의 충실한 경험담이 있습니다. 혼자서 고생하시지 마시고, 쉽게 정보를 구할 수 있다면 이용하는게 맞다고 봅니다.
UNP 는 내용을 본다면 책값이 너무 싼 편에 속한다고 생각합니다.
참고말씀 감사합니다.
예 그렇습니다. 저같은경우 timeval 안에 값을 0,0 으로 셋팅합니다.
그래서 read 나 write 이 셋 되지 않고 셀렉트가 0을 리턴하는군요.
궁금한점은 select 가 0을 리턴했어도 다음번,또 다음번 select 호출시에는
read 나 write 가 왜 셋되지 않을까 입니다. timeval 값을 0,0 으로 하면
select 가 read 나 write 을 셋하기에는 너무 짧은 시간인지요?
UNP 번역판을 전 회사에서 본적이 있는데 번역기를 돌린건지
번역이 이상하더군요.. 살려고 했는데 번역본에 대한 실망때문에
망설이고 있었습니다. 이참에 맘먹고 장만해야겠네요..^^
그나마 2nd Ed. 은 번역이 낫긴합니다만 만족스럽지 못합니다. (번역
그나마 2nd Ed. 은 번역이 낫긴합니다만 만족스럽지 못합니다. (번역자의 악명은...)
가능한 원서를 완독하시는 것이 좋다고 봅니다. 번역본을 보면서 원서를 읽는 것도 나쁘지 않다고 생각합니다.
마지막 글에 질문이 있었군요... 처제네 집들이를 하는 와중에 쓴글이라
마지막 글에 질문이 있었군요... 처제네 집들이를 하는 와중에 쓴글이라 경황이... -_-;
넌블러킹 connect 를 호출 후에 성공이냐 실패냐를 정확하게 판단할 수 있는 시점은 select 에서 넘어오는 순간입니다. 만약 select 를 대기없이 조사만하도록 했다면 (만료시간 0) 이것은 connect 시도의 상태만을 알아보는 것이므로 성공/실패 여부를 알아보기에는 조금 힘든 방법 같습니다.
일반적으로 상대편 서버가 다운되어 있을 때, connect 를 시도하면 보통 60초정도 (환경마다 다르겠죠) 있다가 성공/실패 여부를 돌려준다고 합니다. 여러번 select 를 호출했다고 해도 이 시간이 되기전에는 어떻게 된 것인지 알 수가 없는 것이고, rasungboy 님처럼 만료시간 0으로 한다면 그 시간이 될 때까지는 계속 0만을 리턴하는 상황이겠습니다. (같은 호스트라면 즉시 성공/실패를 판단)
결국 넌블러킹 connect 후에 select 로 일정 시간을 대기해야 한다는 결론입니다. 하지만...
지금 하시고자 하는 것이 여러 다른 일반 fd 들과 함께 connect 시도도 병행하고자 하는 것으로 보입니다. 이럴 경우 문제가 있는데, select 에 주어지는 시간 만료는 여러 fd 들에게 독립적인 것이 아니라 select 자체에 대한 시간 만료이기 때문에 시간에 대한 처리를 따로 하셔야 한다는 것입니다.
각 fd 별로 타임 아웃 시간을 각각 적용하기 위해서는 각 fd 별 타임 아웃을 우선 순위 큐 등을 이용해서 가장 짧은 시간을 select 의 시간 만료값으로 주고 처리해야 합니다. 이것을 제대로 구현하기가 좀 까다롭고 테스트하기도 귀찮고... 좀 그렇습니다...
select 로 분기하는 구조로 간다면 이래저래 처리해야 할 것도 많아지고 상태 머신이 아주 복잡해지는 경향이 있습니다. (간단한 처리 서버라면 상관없겠지만요...) 그래서 대부분 그냥 일반 쓰레드를 사용하거나 특수하게 서버용 사용자-공간 쓰레드를 사용하기도 합니다.
쓰레드라는 것이 막 쓰기에는 그렇지만 좀 신경을 쓴다면 그리 효율을 떨어뜨리지 않고서도 로직의 흐름대로 프로그래밍할 수 있어서 좋다고 생각합니다. (물론 남용은 금물...)
댓글 달기