1. 서론
이슈 제기 하셨던 분, 본인은 OPEN_MAX로 통과했으면서.....
우연히 제 이야기가 거론되는것을 들었습니다.
네. 맞습니다. OPEN_MAX를 활용한 정적배열을 사용하여 통과했을 직접 밝혔습니다.
저는 당시에 파일 오픈 최대값을 의미하는 OPEN_MAX를 무조건 알 수 있고, 이를 활용한 코드가 올바르다고 오해하고 있었습니다. 그래서 오히려 리스트를 사용하는것에 거부감을 가지고 있었습니다.
그때 읽어들인 스트링을 합치는 과정에서 리스트를 활용하면 나름의 이점이 있다는 것을 듣게 되었고, 저는 보너스에서 FD쪽은 OPEN_MAX를 활용한 정적배열을 사용하고, 스트링을 합치는 과정을 리스트를 활용하여 구현했습니다.
그리고 추가로 이슈 제기전, 주말과 월요일 당일을 활용해 FD쪽을 리스트로 구현하는 코드를 작성했고, 테스터기까지 통과함을 확인했습니다. 결코 ‘난 OPEN_MAX로 통과했지만, 너흰 안돼.’ 라는 식의 이슈 제기가 아니였음을 말씀드리고 싶습니다.
이슈 제기의 목적
저는 과제를 통해 올바른 고민을 많이 할 수 있기를 바라고 있습니다. 그래서 제가 제기한 것이 ‘OPEN_MAX를 활용한 배열은 무조건 틀리게 하자’가 아니라, ‘OPEN_MAX 관련하여 시스템 한도에 대해 고찰해보는 것도 굉장히 유용하니, 이것을 유도하자’ 였던 것입니다.
2. 최근 포스팅에 대한 디펜스
참고로 sungjpar님처럼 OPEN_MAX에 대해 고찰을 가져봤던 사람에게는 PASS 기꺼이 주는것도 나쁘지 않을까가 저의 의견입니다.
별도로 테스트 코드를 만들어 돌려 ulimit 을 통해 해제를 하더라도 약 4만 개 이상의 파일은 더 이상 열리지 않음을 확인했다
저는 클러스터의 맥 환경에서 너끈히 4만개 이상의 FD가 열리는 것을 확인했습니다.
테스트 코드1
m1 macbook air 환경에서는 file descriptors를 90000으로 해제하더라도 10240개 이상 열리지 않는다.
앞서 클러스터의 Mac 환경에서는 4만개 이상의 fd가 열림을 확인했습니다. 또한 작동 환경에 따라서 변화하는 값에 의존하는것은 잘 못된 선택이라고 봅니다. 그리고 파일을 OPEN_MAX까지 직접 open하지 않더라도 dup2()를 통해 fd값을 높게 설정하는 것은 아주 쉽게 가능합니다. (pipex를 선택하시면, 사용할 함수입니다.)
테스트코드2
작은 결론
포스팅에서 주장하셨던 것처럼, OPEN_MAX로 방어가 불가능합니다. 단 하나의 파일을 여는것 만으로 fd를 초과시킬 수 있으니깐요. 그래서 리스트로 구현하는 것의 적절성에 대해서 의구심이 들더라도, 이러한 공격에서 방어할 수 있는것은 가변적으로 생성할 수 있는 방식 뿐입니다.
3. 핵심은 진정한 의미의 OPEN_MAX를 알 방도가 없다는 것
리눅스 버전에 따라 limits.h에 OPEN_MAX가 없는 까닭
효용이 없기 때문입니다. limits.h에 매크로되어 있는 값이더라도 그 값이 고정된 값이 있고, 파일오픈최대값 처럼 쉽게 변경가능한 값이 있습니다. 이전에는 어디에선가 쓰일 효용이 있기에 매크로값으로 정의되어 있었지만, 특히 최신 버전의 리눅스에서는 OPEN_MAX라는 값이 사라진 것입니다.
OPEN_MAX를 얻는 올바른 방법은?
파일오픈최대값은 결코 사소하지 않은 값인데 그러면 어떻게 얻어야할까요?
런타임시에 unistd.h에 구현되어 있는 sysconf() 시스템호출을 통해 얻을 수 있습니다. 저희 GNL에서는 허용되지 않는 함수이기 때문에, 진정한 의미의 OPEN_MAX값을 필요할 때 얻을 수가 없습니다.
4. 결론: 이슈제기의 목적은 올바른 고민의 방향 설정
이슈제기의 시작점은 제 뒷자리에서 한 시간을 OPEN_MAX로 옥신각신하던 평가였습니다. 결국 뚫지 못하고 끝나셨는데, 과연 그 한 시간의 평가를 통해 서로 무엇을 얻어갔을까요?
많은이들이 올바르게 알고 있다면 제가 굳이 랜덤채널에 이슈제기를 하지 않더라도, 올바른 지식이 퍼지고 퍼질 것이라 생각합니다. 이슈제기를 할 까닭은 자연스레 그렇게 되지 못 할 것이라 생각되었기 때문입니다.
쪼잔한 발언을 하자면, 사실 이런 이슈에 휘말리지 않는 방법은 보너스를 리스트로 구현하거나 보너스를 포기하는 방법입니다. GNL을 마무리 하지 않고는 과정 진행이 불가능하지만, 보너스를 할 것인지는 전적으로 개인의 선택입니다. (프엪 보너스는 거의 다 스스로 안 하시는것처럼)
앞에서도 밝혔듯이, 실제 제출에서는 join하는 부분에 리스트를 활용했고, 이슈제기전에는 fd 부분을 리스트를 활용해 다시 한번 구현했습니다. 주어진 함수 10개의 제약과 25줄의 압박을 딛고, 개인적으론 구현을 해냈음에 뿌듯함을 느꼈지만 이것을 다른이들에게도 권유한만한가.....는 그렇지 않습니다. 오히려 프엪의 경우에는 보너스까진 해야 프엪의 참맛을 느끼는것이라 생각해서, 넉넉하게 도전해볼 분에게는 권하지만, GNL 보너스 리스트 구현은.....
그래서 배열활용 & OPEN_MAM에서 비롯되는 시스템 한도에 대한 고찰 이 더 난이도 대비 깨닫는 바가 커서 샛길을 열어줘도 좋지 않을까 제시한 것입니다.
제가 평가에서 어떻게 할지, 여러분이 어떻게 할지, 구현을 어떤 방식으로 결정할 것인지는 결국 개인의 몫입니다. 하지만 올바른 방향성이란게 있다고 생각해서, 유도를 해보려고 했는데 의도대로 흘러가고 있는 것인지는 모르겠습니다. (실패한듯....)
