blocking 모드일때 (다 이렇게 시작하죠), 수신쪽 recv buffer가 꽉차고, 송신쪽 send buffer가 꽉차면 block 될 수 있습니다.
감사합니다. 그러면 이런 경우에 해결책은 어떻게 되는지요? 클라이언트를 죽이더라도 서버를 죽일수는 없으므로, 그냥 클라이언트를 죽여버리고 싶은데.. send() 함수가 블럭될것이라는걸 미리 알아야 죽이던 살리던 할텐데 말이죠. send() 호출 직전에 select() 를 호출해서 "쓰기 가능하다"는 것을 보장받은 상태인데도, 막상 send() 호출해보면 블럭되버립니다. send() 가 블럭될것이라는 것을 미리 알 수 있는 방법은 없나요?
non-blocking 소켓으로 만드시고 EWOULDBLOCK을 잡아 내십시오. send가 블럭 되야 할 상황에서 넌블럭 소켓은 EWOULDBLOCK(or EAGAIN)을 리턴해 줍니다. 이 경우 다시 select로 돌아가서 write event를 기다려야겠죠.
참고로 select, pool등의 이벤트 대기류 함수를 쓰면서 싱글 스레드 프로그램을 작성하실 땐 non-blocking socket을 써 주셔야 합니다. 싱글 스레드 프로그램에선 소켓의 입출력시 블럭킹 되는 상황이 치명적이기 때문입니다. 그 동안 다른 소켓의 이벤트들은 전부 대기하고 있어야 하죠. 이런 류의 프로그램에선 프로그램의 흐름을 멈출 수 있는 부분은 오직 select로 한정하시는 것이 좋습니다. blocking I/O를 유발하는 여타 함수들 역시 피해주시는 게 좋고요..(FLIE I/O등)
blocking 모드일때 (다 이렇게 시작하죠), 수신쪽 recv buf
blocking 모드일때 (다 이렇게 시작하죠), 수신쪽 recv buffer가 꽉차고, 송신쪽 send buffer가 꽉차면 block 될 수 있습니다.
---
http://coolengineer.com
...
감사합니다. 그러면 이런 경우에 해결책은 어떻게 되는지요? 클라이언트를 죽이더라도 서버를 죽일수는 없으므로, 그냥 클라이언트를 죽여버리고 싶은데.. send() 함수가 블럭될것이라는걸 미리 알아야 죽이던 살리던 할텐데 말이죠. send() 호출 직전에 select() 를 호출해서 "쓰기 가능하다"는 것을 보장받은 상태인데도, 막상 send() 호출해보면 블럭되버립니다. send() 가 블럭될것이라는 것을 미리 알 수 있는 방법은 없나요?
send, sendto 호출시 flag 에 MSG_DONTWAIT 를 주
send, sendto 호출시 flag 에 MSG_DONTWAIT 를 주면 block 상황이 발생할 경우에 EAGAIN 이 return 된다고 man page 에 나와있네요.
혹은 socket 생성시 non-block type 으로 하셔도 될듯.
non-blocking 소켓으로 만드시고 EWOULDBLOCK을 잡아 내
non-blocking 소켓으로 만드시고 EWOULDBLOCK을 잡아 내십시오. send가 블럭 되야 할 상황에서 넌블럭 소켓은 EWOULDBLOCK(or EAGAIN)을 리턴해 줍니다. 이 경우 다시 select로 돌아가서 write event를 기다려야겠죠.
참고로 select, pool등의 이벤트 대기류 함수를 쓰면서 싱글 스레드 프로그램을 작성하실 땐 non-blocking socket을 써 주셔야 합니다. 싱글 스레드 프로그램에선 소켓의 입출력시 블럭킹 되는 상황이 치명적이기 때문입니다. 그 동안 다른 소켓의 이벤트들은 전부 대기하고 있어야 하죠. 이런 류의 프로그램에선 프로그램의 흐름을 멈출 수 있는 부분은 오직 select로 한정하시는 것이 좋습니다. blocking I/O를 유발하는 여타 함수들 역시 피해주시는 게 좋고요..(FLIE I/O등)
...
답변 감사드립니다. non-blocking 소켓으로 문제를 해결했습니다.
댓글 달기