728x90
반응형

1. Epoll?

Epoll은 리눅스에서 select의 단점을 보완하여 사용할 수 있도록 만든 I/O통지 모델이다.

파일 디스크립터를 사용자가 아닌 커널이 관리를 하며, 그만큼 CPU는 계속해서 파일 디스크립터의 상태 변화를 감시할 필요가 없다.

즉, select처럼 어느 파일 디스크립터에 이벤트가 발생하였는지 찾기 위해 전체 파일디스크립터에 대해서 순차검색을 위한 FD_ISSET 루프를 돌려야 하지만, Epoll의 경우 이벤트가 발생한 파일 디스크립터들만 구조체 배열을 통해 넘겨주므로 메모리 카피에 대한 비용이 줄어든다.

 

#incude <sys/epoll.h>

int epoll_create(int size)

   

fd들의 입출력 이벤트 저장을 위한 공간을 만들어야 하는데, epoll_create는 size만큼의 입출력 이벤트를 저장할 공간을 만든다. 그러나 리눅스 2.6.8 이후부터 size 인자는 사용되지 않지만 0보다는 큰 값으로 설정을 해 주어야 한다. 커널은 필요한 데이터 구조의 크기를 동적으로 조정하기 때문에 0보다 큰 값만 입력하면 된다.

    

반환 값으로는 정수형 데이터가 반환이 되는데, 이를 일반적으로 epoll fd라하며 이 fd를 통해 앞으로 epoll에 등록 된 fd들을 조작하게 된다. 


int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

epoll_ctl은 epoll에 fd들을 등록/수정/삭제를 하는 함수인데 일반적으로 epoll이 관심을 가져주길 바라는 fd와 그 fd에서 발생하는 관심있는 사건의 종류를 등록하는 인터페이스로 설명된다.

 

* epfd : epoll fd 값

* op : 관심가질 fd를 등록할지, 등록되어 있는 fd의 설정을 변경할지, 등록되어 있는 fd를 관심 목록에서 제거할지에 대한 옵션값

* fd : epfd에 등록할 관심있는 파일 디스크립터 값

* event : epfd에 등록할 관심있는 fd가 어떤 이벤트가 발생할 때 관심을 가질지에 대한 구조체. 관찰 대상의 관찰 이벤트 유형


int  epoll_wait(int  epfd,  struct epoll_event * events, int maxevents, int timeout)

epoll_wait는 관심있는 fd들에 무슨일이 일어났는지 조사한다. 다만 그 결과는 select나 poll과는 차이가 있다. 사건들의 리스트를 (epoll_event).events[] 의 배열로 전달한다. 리턴값은 발생한 사건들의 갯수가 리턴된다.

* events : 이벤트가 발생된 fd들을 모아놓은 구조체 배열.

* maxevents : 실제 동시접속수와 상관없이 maxevents 파라미터로 최대 몇개까지의 event만 처리할 것임을 지정해 주도록 하고 있다. 만약 현재 접속수가 1만이라면 최악의 경우 1만개의 연결에서 사건이 발생할 가능성도 있기 때문에 1만개의 events[] 배열을 위해 메모리를 확보해 놓아야 하지만, 이 maxevents 파라미터를 통해 한번에 처리하길 희망하는 숫자를 제한할 수 있다.

* timeout : epoll_wait의 동작특성을 지정해주는 중요한 요소인데, 밀리세컨드 단위로 지정해주도록 되어 있다. 이 시간만큼 사건발생을 기다리라는 의미이며 기다리는 도중에 사건이 발생하면 즉시 리턴된다.

-> timeout(-1)로 지정해주면 영원히 사건을 기다리는 blocking상태가 된다.

-> timeout(0)로 지정해주면 사건이 있건 없건 조사만 하고 즉시 리턴하는 상태가 된다.


Edge Trigger(ET)

 

특정 상태가 변화하는 시점에서만 감지.

 

특정 디지털 신호 000 111 000 111 000 111 일 경우 신호가 0에서 1로 변하는 시점에서만 이벤트가 발생한다.

소켓 버퍼에 대응하면, 한번에 읽을 수 있는 데이터 버퍼가 600인데, 데이터가 1000바이트가 도착했다면, 600바이트만 읽고 나머지 400바이트는 읽지 않은 상태에서 더 이상의 이벤트는 발생하지 않는다.

읽은 시점을 기준으로 보면 더이상의 상태 변화가 없기 때문이다.

따라서 한번에 읽을 수 있는 바이트 이상의 데이터가 오게 된다면 추가적인 작업을 따로 해주어야 한다.

 

ET로 작동하게 하려면 Non-blocking 소켓으로 생성해 줘야 하며 epoll에 관심 FD로 등록 할 때 EPOLLET로 설정해 주어야 한다.

 

서버의 트리거 모드가 엣지 트리거인 경우, 한번에 전송 가능한 패킷 버퍼 사이즈보다 보내야 하는 데이터의 사이즈가 더 클 경우, 여러번에 걸쳐 write를 하게 되면 엣지 트리거의 특성상 정상적으로 데이터를 전부 읽어드릴 수 없는 경우가 생긴다.


Level Trigger(LT)

 

특정 상태가 유지되는 동안 감지.

 

특정 디지털 신호 000 111 000 111 000 111 에서 1에 대한 Trigger 라면 1이 유지되는 시간동안 횟수에 상관없이 이벤트가 발생한다.

소켓 버퍼에 대응하면, 한번에 읽을 수 있는 데이터 버퍼가 600인데, 데이터가 1000바이트 도착했다면, 600바이트를 읽고 소켓 버퍼에 아직 데이터가 유지되고 있는 1인 상태이기 때문에 한번 더 이벤트가 발생하여 나머지 400바이트를 읽게 된다. 즉, 소켓 버퍼가 비어지는(0이 되는) 순간까지 계속해서 이벤트가 발생이 된다.

 

LT는 기본으로 설정되어 있으며 select나 poll은 LT만 지원이 된다.

 

서버의 트리거 모드가 레벨 트리거인 경우, 입력 버퍼에 데이터가 수신된 상황에서 이를 빠르게 읽어들이지 않으면 epoll_wait() 함수를 호출할 때 마다 이벤트가 발생하게 된다. 이로인해 발생하는 이벤트의 수가 계속 누적되는데, 이를 현실적으로 감당하는건 불가능하다. 따라서, 정상적인 접속-접속종료 테스트에 대한 처리가 불가능해질 수 있다.



출처: https://rammuking.tistory.com/entry/Epoll의-기초-개념-및-사용-방법 [쥬리스티앙 죠르즁]

728x90
반응형
728x90
반응형

모든 과정이 동일한지 모르겠지만 내가 겪은 이야기를 하자면

나는 서류 합격후 전화면접을 약 30분간 진행했다.

질문은 나의 경력위주의 질문이었으며 그렇게 압박을 하는 질문은 없었다.

면접을 어떻게 해야 잘 보는 것인지 정답은 없겠으나, 그리고 나는 늦은 나이에 실무경험이 많은 사람이지만,

그래서 오히려 더 부담스럽고 그래서 더 긴장되었고 떨렸다.

나보다는 회사 경력이 적은 대리급이나 과장급의 사람들과 비교했을 때 나는 경쟁력이 있다고

생각하지 않기 때문에, 결국은 그것이 들통나지 않기를 바라는 마음때문에 나는 자신감이 없는 것 같다.

나의 회사 생활을 돌이켜보면 한편으로는 전력을 다하지 않았다는 부끄러움과

그럼에도 불구하고 내가 과연 회사에 내 모든것을 바쳐야 하는 것인가 하는 회의감,

그리고 내가 전력을 다해도 힘든 회사생활이라면 그곳은 나에게는 벅찬 곳이라는 생각이 여태까지 나를 괴롭혀 왔다.

그리고 우연한? 기회로 나는 지금은 백수가 되어 아주 곤란한 나이에 구직을 하고 있다.

소위 말하는 좆소기업을 가야하는지 아니면 이름있는 기업에 다시 들어가야 하는지 도통 모르겠다.

내가 이나이에 없는 실력으로 이름있는 기업에 다시 들어갈 수는 있는지.

그렇다고 이름없는 중소기업을 가자니 내 자존감이 많이 떨어지고.. 연봉도 떨어지고..

 

728x90
반응형
728x90
반응형

1. 테슬라: 2022년 2월 2일

2. 애플: 2022년 2월 1일

3. MS: 2022년 1월 27일

4. 아마존: 2022년 2월 3일

5. 구글: 2022년 2월 2일

6. AMD: 2022년 2월 1일 

7. NVDA: 2022년 2월 17일

 

728x90
반응형

+ Recent posts