udp 패킷 recv 시 select 와 poll 의 차이점 ???
글쓴이: air74 / 작성시간: 월, 2005/02/21 - 8:12오후
안녕하세요.
하나의 소켓에 대하여 recv시 blocking 을 피하기 위하여 현재는 poll(pollset, ct , 0)을 사용 하였습니다.
/*설정된 횟수 만큼 루프를 돌면서 가능한한 모든 메세지 수신한다. */ while (loop_count < thresh){ events = poll(pollset, ct , 0 ); /* no blocking */ if (events > 0) { rval = recvmsg(sn_xudp.fd, &msg_hdr, 0); queuing_msg(); /*-> 수신한 메세지 큐잉 */ } loop_count++; }
여기서 질문 드립니다.
1. 시스템 성능상에서 보면 poll 대신에 select 쓰는 것이 잇점이 있을까요? (select 가 poll 보다 시스템 리소스를 적게 사용 한다는지?)
어차피 블락킹을 피하기 위한 것이니 예를 들면
select(n, *readfds, *writefds, *exceptfds, *timeout -> 타임아웃을 0 );
2. 비슷하지만 다른 질문 입니다. 위에서 poll 을 빼고 recvmsg(sn_xudp.fd, &msg_hdr, MSG_DONTWAIT); 로 바꾸어서 구현을 해보았더니 stack over flow 가 나는거 같더라구요. ?
소켓 버퍼가 풀나는거 같습니다. 추축컨데... 원래 그런것인가요? 아래는 소스 입니다.
void getting_events_from_network(void) { struct sockaddr_in msg_addr; struct iovec msg_iovector[MSG_IOVECTOR_NUM]; /* always two */ struct msghdr msg_hdr; sn_msg_message *msg; /* possible compile ??? */ int rval; int msg_addrlen; int loop_count; int xgw_loop_count; char in_buff_head[HEAD_BUFFER_SIZE]; /* -> for msg header */ char in_buff_data[DATA_BUFFER_SIZE]; /* -> for msg data */ memset(in_buff_head, 0, HEAD_BUFFER_SIZE); memset(in_buff_data, 0, DATA_BUFFER_SIZE); msg_iovector[0].iov_base= in_buff_head; /* msg_header size predefined */ msg_iovector[0].iov_len = HEAD_BUFFER_SIZE; msg_iovector[1].iov_base= in_buff_data; msg_iovector[1].iov_len = DATA_BUFFER_SIZE; msg_addrlen = sizeof(msg_addr); bzero(&msg_hdr, sizeof(msg_hdr)); msg_hdr.msg_name = &msg_addr; msg_hdr.msg_namelen = msg_addrlen; msg_hdr.msg_iov = msg_iovector; msg_hdr.msg_iovlen = MSG_IOVECTOR_NUM; loop_count = 0; while(loop_count < xgw_loop_count) { rval = recvmsg(sn_xudp.fd, &msg_hdr, MSG_DONTWAIT); /* asyncronous msg redving */ if (rval > 0) { process_msg(msg_hdr); } loop_count++; }
Forums:
xgw_loop_count가 초기화되지 않고 사용되었네요. 그것때문이 아
흠... 그리고 msg_control 이 제대로 초기화안된게 원인이 아닐까 하네요.
그런데 udp포트를 몇개나 여시는지는 몰라도.. 보통 udp포트는 그리 많이 열지 않을텐데요.
저같은 경우 udp 포트에 대한 이벤트 대기는 udp 소켓당 recvfrom 블러킹을 들어갈 쓰레드 하나를 잡아서 처리합니다. 굳이 이벤트 검출하거나 할 필요가 없으니까요.
send의 경우 tcp처럼 wouldblock 이 걸리는 것도 아니고, connect를 받는 것도 아니니.. udp 포트를 몇십개 씩 열지 않는 이상은...
블러킹을 피하기 위해 이벤트 검사 루프를 돌리면 그만큼 다른 쓰레드의 시간을 대기에 빼앗게 되며, 불필요한 cpu 점유율을 잡아먹게 되니까요.
님ㅎ 즐~
댓글 달기