반응형

부끄러운 사실이지만, 최근 들어서야 코딩할 때 파이썬(python)을 쓰기 시작했다.

말이 최근이지 불과 이틀 전이다. ㅡㅡ;;


애초에 네트워크 시뮬레이션 특성상 핵심 구현은 C/C++을 쓸 수밖에 없고, 똑같은 것을 실제 장비에서 실험을 해보려면 리눅스 디바이스 드라이버를 고쳐야 해서 결국 C를 써야 한다. 전에 연구실에서 IoT 테스트베드 구현에 깊게 참여하던 당시에는 IoT 미들웨어가 순수 Java로만 되어 있었고, 과제 연차평가를 보여줄 시연용 모바일 기기도 안드로이드여서 Java 기반이니 지금껏 Java와 C/C++만 줄기차게 써온 셈이다.


물론 스크립트 언어를 안 쓴 것은 아닌데, 그게 리눅스 쉘(shell) 스크립트와 awk였다. QualNet이나 ns-3가 만들어 내는 수많은 반복 시뮬레이션을 batch로 실행하고, 실행 후에 만들어지는 여러 개의 데이터 텍스트 파일들을 정리해서 엑셀이나 Gnuplot에 붙이기 좋게 만들 필요가 있었다. 

문제는 shell (bash)이든 awk든 스크립트 언어라서 바로바로 돌려볼 수 있기는 한데, 왠지 코드가 쉽게 써지지 않는 것은 단지 나의 기분탓이었을까? (...)


사실 bash나 awk 모두 잘(?) 쓰면 아주 강력한 스크립트 언어인 것은 분명하지만, 이상하게 빨리 익숙해지는 느낌은 잘 들지 않았다. 내가 집중적으로 실험할 때에만 폭풍처럼 몰아쳐서 스크립트를 만들다가 또 한참 안쓰고 잊어버려서 그런 것일지도? 아무튼 awk로 내가 머릿속에서 상상하는 것처럼 텍스트를 예쁜 과일 자르듯 쉽게 파싱하려면 상당한 시간의 구글링과 trial-and-error를 거쳐야만 했다.


최근에도 bash와 awk의 조합으로 ns-3 시뮬레이션을 대량으로 돌리고, 그 결과로 생성되는 텍스트 파일 중에서 몇몇 지정된 노드 번호에 대해서만 로그 데이터를 읽어들여서 파싱하는 작업을 했는데, 최근에 요구사항이 추가돼서 결과 데이터를 한번 더 가공해야 하는 상황이 되었다.

이미 만들어 놓은 awk 코드를 또 고치려니 선뜻 손이 가지 않아서, 차라리 파이썬으로 해 봐야겠다는 생각이 들어서 그냥 파이썬의 파일 입출력 예제 코드와 string 포맷팅 등의 기초적인 정보를 구글링해서 만들어 보았다.


그랬더니,


...15분 만에 결과 데이터가 내가 원하는 형태로 터미널 화면에 뙇.


Aㅏ...


기존의 awk와 shell 스크립트를 뜯어고치면 절대 완성하지 못할 시간인데...

그리고 다른 데이터에 대한 유사한 후처리 작업을 ns-3 시뮬레이션 상에서 C++ 함수로 구현해 둔 것도 있는데, 그 당시에 구현하던 때에도 30분 넘게 걸렸었는데 파이썬은 문법을 구글링하고 vi에서 생으로 코드를 짰는데도 15분이라니.

게다가 그동안 자바로 코딩했던 경험상, 똑같은 기능을 자바로 구현하면 100줄은 쉽게 넘어갈 코드가 파이썬에서 주석과 디버그용 print문 합쳐서 45라인...


...난 지금까지 뭘 한거지? ㅋㅋㅋㅋㅋ


예전에 오버레이 네트워크 상에서 돌리는 라우팅 프로토콜을 만들어야 된다고 징징거릴 때, 주변에서 파이썬으로 먼저 만들어 보는 건 어떠냐는 제안에도 파이썬을 써본 적이 전혀 없어서 익숙한 Java로 하겠다고 그랬는데...

테스트용 웹서버 구축할 때에도 Spring Boot 상에서 자바로 노동(?)을 하고 있을 때에도 옆에서 아는 형이 Django로 파이썬으로 만들면 더 빠르다고 했을 때에도 선뜻 바꿀 생각을 못했는데... @_@ (정신 가출)


다양한 프로그래밍 언어로 문자열 처리 어플리케이션 개발 시 소요되는 시간 비교(Prechelt and Garret) (출처: HACKERNOON [1])


위의 그래프가 충분히 이해가 가는 순간이다.


게다가 내가 목표로 하는 개발환경은 실행속도 따위(...) 그다지 의미가 없고, 코드만 빨리 완성되면 가상 머신 여러 개 만들어서 밤에 자는 동안 batch로 잔뜩 돌려놓기만 하면 되니까... 진작에 파이썬을 여기저기 적용해서 쓸 걸 ㅠㅠ


게다가 파이썬을 단 한번도 써본 적 없다고 괜히 겁먹은 거잖아?!

기존에 다른 프로그래밍 언어들을 장시간 다뤄본 사람 입장에서 파이썬은 배울 필요 없이 그냥 일단 쓰고 보면 되는 거였다. ㅡㅡ;;


물론 텍스트를 잘 파싱/편집/재구성하는 가장 강력한 도구로써 awk를 쓰는 것이 여전히 더 유리한 상황은 있을 것이다. 하지만 비교적 단순한 스트링 파싱은 그냥 파이썬에서 직관적인 코드를 써서 훨씬 더 빨리 만들어낼 수 있음을 이번에 경험으로 알게 되었다.

앞으로는 C++ 시뮬레이션 코드를 bash로 반복 실행을 하고, awk로 여기저기 흩어진 데이터를 한데 모으는 것까지만 하고, 그 뒤의 스트링 파싱이나 평균 계산 등은 다 파이썬으로 하면 될 것 같다.


생산성이 좋다고 주변에서 일관되게 얘기하면 그러한 줄 알고 신속하게 적용할 수 있는 사고방식의 중요성을 느낀다. ㅠㅠ

외곬수가 되지 말자...



<참고자료>

[1] Nick Humrich, "Yes, Python is Slow, and I Don’t Care," HACKERNOON,

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1



반응형
블로그 이미지

Bryan_

,
반응형

1. 찾아서 바꾸기 기능 쓸 경우:


:%s/\t/[원하는 공백 크기]/g


예를 들어, 4칸의 공백으로 바꿀 경우,


:%s/\t/    /g




2. VIM에 정의된 다른 명령어의 조합으로:


:set expandtab

:set ts=4

:retab


set ts=4에서 ts를 원하는 숫자로 바꾸면 바뀐 크기만큼 적용된다.




반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 16.04 (amd64)

Version: ns-3.26

gcc: 4.8.4



*결론부터 말하면, 소스 파일 확장자를 반드시 .cc 로 맞추자.



ns-3 에서 바로 시뮬레이션 코드를 테스트할 때 scratch 디렉토리에 소스코드를 집어넣으면 되고, 이 때 객체지향 컨셉을 적당히 쓰기 위해 하나의 클래스를 독립된 헤더와 소스 파일로 만드는 경우가 있다.


헤더와 소스 파일을 만들 때, [클래스 이름].h, [클래스 이름].cc 로 맞춰서 만들어야 하는데, 실수로 소스 파일 확장자를 cc가 아닌 cpp 또는 그외 다른 확장자로 쓰게 되면 ns-3의 waf 스크립트에서 소스 파일만 인식을 못해서 빌드 과정에서 "undefined reference to X" 에러가 발생한다.


문제는 이클립스 CPP 환경에서 ns-3를 프로젝트로 로드해 와서 scratch 폴더 내부에 클래스를 생성할 때에는 소스 파일의 확장자가 .cc이든 .cpp이든 아무 경고 메세지가 발생하지 않는다. 나도 이클립스 CPP에서 New > Class 메뉴를 통해서 자동으로 클래스를 만들면서 소스 파일 확장자가 .cpp로 만들어지는 것을 미처 인지하지 못해서 이 링크 에러를 보게 되었다.


ns-3.26/build/scratch 디렉토리를 살펴 보니 아예 내가 만든 클래스에 대한 오브젝트 파일(.o) 파일이 존재하지 않았다. 그 원인은 ns-3.26/wscript 파일에서 소스 파일을 자동으로 불러올 때 .cc 파일만 인식하게 되어 있기 때문이다.


(ns-3.26/wscript 파일 일부)

...(앞부분 생략)...

elif filename.endswith(".cc"):

name = filename[:-len(".cc")]

...(이하 생략)



wscript 파일을 고쳐서 cpp 파일도 자동 인식하도록 만들어도 되지만, 일단 ns-3에서 scratch 디렉토리에 대해서 미리 정해져 있는 컨벤션이고, 나중에 시뮬레이션 코드만 다른 컴퓨터의 다른 ns-3 버전에서 돌려야 할 때 같은 문제가 또 발생하게 되므로, 그냥 소스 파일을 .cc로 맞추는 것이 안전한 방법이 되겠다.



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 16.04 (amd64)



우분투에 와인을 설치해 두고 쓰다 보면 몇몇 확장자의 파일에 wine에서 작동하는 어플리케이션들이 "Open With" 메뉴에 선택 항목으로 표시된다.

몇 가지 예를 들어 보면:


txt 파일에서 Open With에 notepad (윈도우 메모장)이 연결되고, 

png, jpg 같은 이미지 파일에는 Internet Explorer가 연결되고,

hwp 파일에는 리눅스용 한컴뷰어 대신 wine에 내장된 한글 워드프로세서가 연결

그외 다수...


우분투에서 wine을 적극적으로 사용하는 경우에는 편리할 수 있지만, 단순한 텍스트 문서를 열고 싶을 때 굳이 wine에 연동된 메모장을 쓰고 싶지는 않을 것이다.


Open With 에 나타나는 wine 기반 윈도우용 어플리케이션 목록을 제거하려면,

텍스트 에디터로 ~/.local/share/applications/mimeinfo.cache 파일을 열고,

"wine-extension-" 문자열이 들어가 있는 라인을 모두 제거한다.


예를 들어, txt 파일에는 wine-extension-txt.desktop과 wine-extension-htm.desktop이 쓰여져 있을 텐데, 이 라인들을 지우고 mimeinfo.cache 파일을 저장한다. 그러면 이후 txt 파일을 마우스 오른쪽 버튼으로 클릭했을 때, Open With에서 더이상 notepad는 보이지 않게 된다.



<참고자료>

[1] https://askubuntu.com/questions/186494/remove-wines-notepad-from-open-with-options

반응형
블로그 이미지

Bryan_

,
반응형

네트워크 시뮬레이터로로 예전부터 1년반쯤 전까지는 QualNet을 써 오다가, 작년부터는 줄곧 ns-3만 쓰고 있는데, 둘 사이에 장단점을 간단히 비교해 볼 수 있을 것 같았다.


주의사항: 주관적인 관점이라서 다른 사용자 입장에서는 의견이 다를 수 있음.




<비용>

QualNet : ns-3 (압승)


*QualNet

 - 대학교에서 University license로 기본 라이브러리만 구매하면 약 1000만원

 - 기본 제공이 안되는 라이브러리 추가 시 약 100~250만원 정도 예상 (LTE, Zigbee 같은 것들이 여기에 해당 ㅜㅜ)

 - 한 번 라이선스 구입하면 무제한 사용

 - 대신 버전 업그레이드 기간에는 제한이 있음. 문제는 시간이 지날 수록 최신 버전을 써야 할 필요가 생긴다는 것. 2010년쯤에 구입했던 5.1 버전에는 기본 제공하는 와이파이 표준이 802.11a/b/g 밖에 없어서 802.11n이나 ac를 테스트할 수가 없었다. 구 버전 사용자가 최신 버전을 쓰려면 본사에 1000달러를 내면 된다고 한다.

 - 멀티코어를 잘 지원해서 시뮬레이션 성능을 높일 수는 있는데, 라이선스 하나에 코어 2개가 최대임. 코어 수 늘리려면 라이선스 더 사야 함(...)


*ns-3

 - 무료 (오픈소스)

 - 버전 업그레이드 되면 그냥 새로 다운받아서 쓰면 됨

 - 오픈소스라서 실시간으로 수정되는 코드를 버전 관리 시스템에서 바로 받아쓸 수도 있다. (물론 그만큼 버그에는 취약. 공식 릴리즈 공지되는 버전만 써도 무방)




<그래픽 유저 인터페이스(GUI)>


QualNet (압승) : ns-3


*QualNet

 - ns-3에 비해 월등히 좋음.

 - 마우스 클릭만 가지고 가장 기본적인 시뮬레이션 실행이 가능한 수준 ㄷㄷ.

 - 파워포인트에서 도형 배치하고 선 긋듯이 노드들 배치하고, 트래픽은 보내는 곳과 받는 곳 사이에 선을 drag & drop으로 죽 그어 주면 만들어짐. 그 선을 더블클릭해서 패킷 사이즈, 보내는 양, 시작시간 등등 다 설정하면 됨. 각 노드도 더블클릭해서 각각의 네트워크 인터페이스, 프로토콜, IP주소, 그외 각종 설정들 다 바꿀 수 있음.

 - 그림 그리기(?)를 끝내고 시뮬레이션 시작(play 버튼)을 누르면 노드와 노드 사이에 패킷 전달되는 과정, 노드의 움직임, 무선일 경우에는 전송 범위까지 실시간으로 시뮬레이션 시간에 맞춰서 다 표시됨. 보여주는 정보의 종류를 조정할 수 있고, 재생되는 속도도 조정 가능. (물론 최고속도는 컴퓨터의 하드웨어 성능에 비례함)

 - 시뮬레이션 끝나면 결과를 그래프로 볼 수 있는데, L1/L2/L3/L4/어플리케이션 계층 각각에 대해서 통계치를 다 볼 수 있음. 예를 들어 PHY 계층에서 signal 발생시킨 수와 에러율 확인, MAC 계층에서 프레임 전송 수와 실패 재전송 수, 라우팅 계층의 경로 탐색 시도 수, 응용 계층에서의 실제 throughput 이 모든 것을 모든 노드에 대해서 다 확인 가능.

 - 물론 GUI만으로 논문 실험에 쓸 만한 자기만의 방법을 설정해줄 수는 없고, 그 부분은 어쩔 수 없이 코드 수정을 해야 함.


*ns-3

 - GUI가 큰 의미가 없음 (...)

 - 애초에 ns-3에는 시뮬레이션 환경 자체를 설정하는 GUI가 존재하지 않음.

 - C++ 코드로 일단 뭐가 됐든 시뮬레이션을 돌려 본 뒤에야 자신이 만든 네트워크 토폴로지가 어떻게 생겼는지 GUI에서 확인 가능. 왜냐하면 ns-3에서 제공하는 NetAnim 이라는 GUI는 실시간으로 시뮬레이션을 시각화하는 것이 아니고, 시뮬레이션 결과 파일을 읽어들여서 재생하는 역할이기 때문. (스타크래프트의 지난 경기 리플레이로 보는 것과 차이가 없음)

 - 앞으로도 눈으로 보는 대로 시뮬레이션 환경을 만들 수 있도록 돕는 GUI가 나올 확률은 낮음. ㅜㅜ 왜냐하면 퀄넷은 시뮬레이션 환경 자체는 별도의 스크립트 파일로 처리하고, 실제 L1/L2/L3/L4 계층의 행동은 C/C++ 코드로 처리하기 때문에 GUI에서 스크립트 파일을 만들어 주는 것이 가능한 반면에, ns-3는 그냥 모두 다 C++로 코딩해야 되기 때문에.

 - 그나마 ns-3 입장에서 위안이 되는 점은, 토폴로지를 눈으로 확인할 필요가 없고 환경을 조금씩 바꾸면서 수많은 반복 실험을 해야할 때가 되면 GUI를 쓸 필요 없이 커맨드 라인에서 배치(batch)를 돌리게 되니까 퀄넷이나 ns-3나 별 차이가 없게 될 것이라는 점. (퍽이나 ㅠㅠ)




<시뮬레이션 성능(scalability, running time 측면)>


QualNet (우세) : ns-3


*QualNet

 - 애초에 퀄넷이 처음부터 내세우는 장점이 scalability이고, 기본적으로 모든 코드에 MPI 적용이 되도록 만들었기 때문에 (사용자가 새로 만드는 코드까지 전부) 멀티 프로세서 지원의 편의 측면에서 ns-3를 압도함.

 - QualNet 판매하는 회사 이름도 심지어 Scalable Networks임 (...)

 - GUI에서는 시뮬레이션 시작 버튼 옆에 프로세서 개수 칸이 있는데 그냥 숫자 써주면 끝.

 - 커맨드 라인에서는 "-mp 2"라고 쓰면 알아서 듀얼코어 써서 돌림.

 - 그냥 싱글코어로 돌려도 꽤 빠른 편임.

 - 다만 GUI에서 실시간으로 시뮬레이션 진행 중인 애니메이션 화면을 봐 가면서 실행하면 당연히 느림. (...) GUI에서 눈으로 확인이 되었으면 커맨드 라인에서 돌려야 함.

 - 유일한 단점이 있다면, 코어 개수도 현질을 해야 3개 이상 쓸 수 있다는 점.

 - 또한 라이선스 때문에 한번에 여러 머신에서 여러 프로세스를 돌리는 것이 불가능함. (라이선스 서버 1개가 라이선스 1개를 프로세스 1개에 할당하는 방식이고, 그 동안에는 다른 프로세스가 실행될 수 없는 구조 ㅠㅠ 동시에 여러 머신에서 시뮬레이션을 돌리려면 머신 개수만큼 라이선스가 있어야 함.)


*ns-3

 - ns-3도 퀄넷처럼 이벤트 기반 처리 방식으로 시뮬레이션을 실행하고, MPI 라이브러리를 통해서 멀티코어를 사용할 수 있기 때문에, 구조적인 측면에서는 퀄넷과 큰 차이가 없음. 하지만 사용의 편의가 떨어지는 게 문제.

 - ns-3에서 멀티코어를 쓰려면 사용자가 수동으로 mpi 관련 라이브러리를 미리 설치해야 하고, 자신의 시뮬레이션 코드에 MPI를 쓰겠다는 설정을 또 별도로 작성해 줘야 함. 단순히 argument에 숫자 추가만 하면 되는 QualNet에 비해 쓰기 어려울 수밖에 없음. (인터넷에도 MPI 적용이 안돼서 질문하는 글이 많음)

 - 모든 코드가 다 MPI가 되는 것도 아님. 특히 와이파이 같은 무선 쪽은 MPI가 아직 안돼서 무조건 싱글코어로 돌려야 함. 이게 특히 심각해지는 부분이 ns-3가 가상 머신들을 연동해서 돌아갈 때.


 - 다만 ns-3가 퀄넷에 비해 유리한 상황이 있기는 한데, 똑같은 시뮬레이션 인스턴스를 1개가 아니라 조건이 조금씩 다른 수백~수천 개의 시나리오를 순차적으로 처리해야 할 때. 퀄넷은 라이선스 1개당 1개 프로세스만 존재할 수 있지만, ns-3는 오픈소스니까 그런 거 없다. 원하는 만큼 클러스터에 복제해서 원하는 만큼 얼마든지 프로세스를 돌릴 수 있음. 즉, 개별 시뮬레이션 처리 시간이 오래 걸리는 문제를 동시에 여러 머신과 프로세스를 써서 얼마든지 전체 시뮬레이션 시간을 줄일 수 있음.




<외부 프로그램과의 확장성>


QualNet : ns-3 (우세)


*QualNet

 - 외부 프로그램에서 패킷을 만들어서 퀄넷의 시뮬레이션 네트워크에 주입하는 것이 가능한데, 방법이 편하지 않음. 외부 프로그램과 퀄넷 사이에 패킷을 서로 전달해 주는 코드를 하나 더 만들어야 함. (이것도 C언어로)


*ns-3

 - 리눅스 컨테이너(lxc)를 써서 VM을 만들어서 그 VM들 사이의 네트워크를 ns-3가 시뮬레이션할 수 있음!!

 - ns-3 시뮬레이션 코드 위에 아예 실제로 작동하는 프로그램 소스코드를 그대로 컴파일해서 돌리는 것(Direct Code Execution; DCE)도 가능!!


 - 그러나 위 2개 다 아직 한계가 있음 ㅠㅠ

 - VM 방식은 호스트 머신(리눅스)에 브릿지 인터페이스에 tap을 붙여서 ns-3와 연결되는데, 여기서 약간씩 딜레이가 발생함. VM들은 자기들만의 clock을 갖고 있는데 ns-3에 약간이나마 늦게 패킷이 흘러들어오면 그걸 ns-3 프로세스가 시뮬레이션으로 처리하고 다시 VM들에게 돌려주는 과정에서 각 VM은 이미 자기 시간이 흘러가고 있음. 결국 실제 환경에 비해서 delay가 커질 수밖에 없는 구조.

 - 게다가 설상가상으로, 와이파이 같은 무선 네트워크 환경에 저렇게 VM을 붙이면 ns-3가 아직(2017.04.15 기준) 무선 환경을 멀티코어로 처리하지 못하기 때문에 무선 환경의 신호 세기, 간섭, fading, propagation 이런 것들을 다 싱글코어에서 계산해야 됨(......)

 - 그래서 VM 10개를 만들고 와이파이 애드혹 네트워크를 시뮬레이션했더니, 각자 1초에 하나씩 hello 메세지를 broadcast하기만 하는데도 그 상태로 ping을 날리면 20초가 넘어가는(...) 도저히 실험 불가능한 상태가 됨. 지못미 ㅠㅠ

 - VM에 대한 대안으로 나온 것이 DCE인데, 이것도 사실 C++로 개발된 프로그램만 취급함. C++ 소스코드를 가져와서 ns-3에서 호환될 수 있게 g++ 옵션을 조금 추가해서 빌드하면 되는데, 그렇다고 모든 시중의 C++ 프로그램이 다 빌드되는 것도 아님. ns-3 커뮤니티 얘네들은 자랑스럽게 iperf를 소스코드 수정 없이 그대로 빌드해서 갖다쓸 수 있다고 자랑하는데, tcpdump 같이 더 심각한 일을 하는 소스코드는 아예 컴파일 불가능 ㅜㅜ

 - 내가 직접 소켓 프로그래밍으로 C++ 프로그램을 만들어서 돌리려고 해도 생각보다 지원 안되는 코드가 많아서 코딩에도 제약이 있음. 이게 뭐야...


 - 결론적으로, 분명히 확장성이 좋아 보이는데 결국 실제로 제대로 써 보려고 달려들면 퀄넷이나 ns-3나 안되는 건 마찬가지임 ㅠㅠ




<통계(Statistics)>


QualNet : ns-3 (무승부)


시뮬레이션 결과에 대한 통계를 내 주는 부분은 양쪽 다 방식도 다르고 장단점도 분명해서 어느 한 쪽이 유리하다고 볼 수는 없다.


*QualNet

 - 위의 GUI 부분에도 언급되어 있듯이, 물리 계층부터 응용 계층까지 각 계층에서 낼 수 있는 모든 통계를 항상 만들어 줌. GUI에서 그래프를 그려줄 때 참고하는 파일이 .stat 파일이고, 시뮬레이션 1개를 실행하고 나면 자동으로 생성되기 때문에 이 .stat 파일을 직접 파싱해서 원하는 통계치를 계산하는 것도 가능.

 - 모든 계층에 대한 통계가 다 나오는 점이 의외로 디버그에 유용할 때도 있음. 가령 응용 계층에서 패킷을 모두 전송 실패했는데 물리 계층에서 받는 signal이 분명히 기록되어 있다면 중간의 라우팅 계층 같은 부분에서 기대와 다르게 패킷을 drop했을 수 있으므로, 라우팅 계층의 logic을 살펴보는 식의 접근이 가능함.


*ns-3

 - 시뮬레이션 환경에서 생성하는 노드 각각에 대해서 .pcap 파일을 자동으로 만들도록 설정할 수 있는데 (코드에 pcap output을 만들어 달라고 1줄 추가하면 됨), 이 pcap 파일을 Wireshark에서 바로 보거나 그래프를 볼 수도 있고, tcpdump에서 약간의 규칙을 적용해서 원하는 정보를 원하는 포맷으로 만들어 쓸 수 있음.

 - pcap 파일을 기반으로 패킷을 분석하고 통계를 내는 부분은 오픈소스 도구들도 여럿 존재하기 때문에 퀄넷의 자체 포맷(stat)에 비해 유리한 점이 있음.




반응형
블로그 이미지

Bryan_

,