반응형

내 개인연구 실험을 위해서 개발하고 있는 서비스 인지 네트워크 아키텍처에서, flow 기반 라우팅 모듈과 traffic shaping 모듈 각각의 모듈 테스트를 성공한 지 어느새 2주 정도가 지났다. 그 외에도 이웃 노드들의 link quality를 실시간으로 측정하는 모듈은 진작에 몇 개월 전부터 완성되어 있었고, 서비스의 요구사항을 인식하는 부분도 오래 전부터 조금씩 완성도가 높아져 있는 상태였다.


하지만 이 모든 것을 연동해서 실제로 서비스가 요청하는 경로 하나를 만들어 내는 것까지 검증하는 연동 테스트에서 계속 시간을 소비하고 있다. ㅜㅜ 모듈 테스트에서 예외상황을 처리한 줄 알았는데 알고 보니 잊고 처리하지 못한 부분에서 기다렸다는 듯이 에러가 발생하고, 미처 생각지 못한 파라미터 값의 불확실성으로 인해서 예외 상황도 새로 생겨났다.


나름대로는 최선을 다해서 치밀하게 코드를 짜려고 했지만, 그리고 최대한 모듈들 간에 인터페이스를 미리 맞춰 두려고 했지만, 결국 실제로 모듈의 기능을 구현/개선하는 과정에서 미리 약속해 둔 인터페이스가 변경되는 일도 발생한다.


설계 단계에서부터 명확하게 잘 하는 것이 중요하다는 것을 피상적으로는 알고 있지만, 현장에 뛰어들어서 직접 코딩하다 보면 그게 말처럼 쉽게 되지 않는다. 설계를 잘 하려고 해도, 커널에 근접해 있는 각종 네트워크 기능들을 충분히 이해하는 상태라야 가능한 영역이 있어서 어려움을 겪곤 한다. 일단 요구사항만 주어진 채 달려들어서 user level 프로그램의 입장에서 구현을 시작하다 보면, (나는 서비스를 도와 주는 미들웨어를 개발하는 입장이니까 일차적으로 user level API에서 Kernel level로 메세지가 전달되는 구조이다.) 커널 영역에서는 실제로 더 많은 세부사항들을 정의해 주어야 하고, user level에서 제시하는 정보가 부족하기 때문에 제대로 작동하지 못하는 경우가 생긴다. 결국 다시 user level 모듈부터 재설계를 해서 다시 Kernel level에 제대로 모든 정보가 흘러들어가는지 확인해야 한다.


두세 번 이렇게 반복하면 설계 단계에서 무슨 정보를 줘야 하는지는 확실해지긴 하지만, 그 다음으로 겪는 어려움은 실제로 주어진 정보를 가지고 원하는 기능이 작동하도록 구현을 하는 것이다. 더 자세히 얘기하자면, 원하는 기능이 "효율적으로" 작동하도록 구현하는 것이다. 사실 효율성이라는 것도 겪어보지 않은 작동 과정을 상상하면서 어디서 어떤 비효율이 발생하는지 예상할 수 있어야 하는데, 그게 잘 상상이 되지 않는 것이 문제다. 실제로 어느 정도 의미 있는 데이터의 범위를 갖고 돌려 보고 나서야 어느 과정에서 비효율이 발생하는지 알 수 있게 된다.


내가 1년 정도만 더 일찍 지금과 같은 노력을 시작했으면 좋았겠다는 후회가 될 때도 있지만, 지금이라도 제대로 실험환경을 구축하고 역량도 키워가는 과정이라는 것에 위안을 삼으며 마음을 다잡곤 한다. 박사과정 학생 신분으로 연구를 자유롭게(?) 계속할 수 있는 기한도 이제 많지 않은데, 그 전에 최대한 경험치와 역량을 쌓고 싶다. 그 동안의 더디게만 올라가던 learning curve가 이제 조금 가파르게 상승할 것 같은 기대감이 생기는 시기에 와 있는데, 이번에 실험환경 구축이 잘 되면 꼭 좋은 논문을 만들어 내야겠다. 일단은 급하게 써야 하는 논문부터 먼저 만들어 내고... ㅜㅜ



반응형
블로그 이미지

Bryan_

,
반응형

무선 메쉬 네트워크에서 멀티홉 라우팅을 하면서, 라우팅을 해야 되는 flow가 아래와 같이 다르면, iptables를 쓸 때에도 필터링을 서로 다른 곳에서 해 주어야 한다:


1) 다른 노드가 source가 되고, 현재의 메쉬 라우터는 중간 노드가 되는 경우

2) (실제로 그럴 일은 별로 없겠지만) 메쉬 라우터 자체에서 패킷이 생성되었을 경우, 즉 메쉬 라우터 자신이 출발지 노드(source)가 돼서 응용 계층으로부터 패킷이 주입되는 경우


특정 포트 또는 목적지로 가는 패킷을 필터링/분류하고 라우팅을 변경하고자 할 때:

- 1번의 경우에는 PREROUTING 단계에서 hook을 걸어야 패킷이 걸린다.

- 2번의 경우는 OUTPUT 단계에 hook을 걸어야 패킷이 걸린다.



<2016.07.17 추가>


내가 하려는 작업은:

  • 멀티홉 라우팅 경로에서 중간노드 역할을 수행하는 라우터가 특정 조건의 패킷에 대하여 마킹을 한다. (--set-mark 옵션)
  • 특정 번호로 마팅된 패킷에 대응하는 별도의 라우팅 테이블을 만들어서 해당 패킷들만을 위한 라우팅 경로를 설정한다.


이 작업을 수행하려면 iptables에서 mangle 테이블을 써야 하고, 이 때 PREROUTING, OUTPUT 체인이 갖는 의미는 참고자료 [1] 에 잘 설명되어 있다.



<참고자료>

[1] http://marcof.tistory.com/35

반응형
블로그 이미지

Bryan_

,
반응형
요즘 들어서 실제 환경에서 내 연구분야와 관련된 지식이 확장되는 기쁨과 동시에 이걸 그동안 모르고 있었다는 절망, 곧이어 또다른 지식의 확장에 대한 경험의 연속이다. 한마디로 말해서 제정신이 아닌 상태다. (...) 전산학/컴퓨터공학의 세부 분야라면 어느 것이나 마찬가지일 것 같은데, 애초에 이론을 완벽하게 습득하지 않은 채로 계속 다음 단계로 전진하다 보면 실전에서 모래성과 같이 허술하게 쌓여 있던 그동안의 지식이 깨지게 되고, 결국 실전에서 문제를 해결하는 과정을 겪으면서 이론을 재정립하고, 실제 환경에서 어떻게 이론이 적용되는지도 배우게 된다. 물론 마지막 단계에 해당하는 '실전에서 문제를 해결하는 과정'이론 기반이 약할 경우 오래 걸릴 수밖에 없다.
내가 석사과정 2년차 때 자의반 타의반으로 무선 네트워크 분야의 연구주제를 선택하면서, 비교적 최근까지 얼마나 내가 이론이 약한 상태였는지를 뼈저리게 느끼고 있다. 달리 표현하자면, 이제서라도 네트워크를 실제로 운용할 때 필요한 일부 요소들(여전히 극히 일부인 것 같다.. 에휴)을 하나씩 재정립하는 것이 얼마나 다행인지 모르겠다. 학생이니까 실수하고 배우는 것이 용서가 되지, 만약 박사가 되어 세상에 나가서 똑같은 경험을 하고 살았다면 부끄러워서 고개를 들고 다니지 못했을 것이다. (뭐 사실 학생 신분도 이제 시한부가 되었다. 무한정 학생일 수는 없다.)
최근에 내 연구의 실험 환경인 와이파이(IEEE802.11) 기반의 멀티채널 무선 메쉬 네트워크(multi-channel wireless mesh network)를 구축하고 실제로 트래픽을 만들어서 보내면서, arp, route (커널 라우팅 테이블), iptables, hostapd, dhcp 등의 다양한 도구들의 역할과 그 중요성을 실감할 수 있었고, 커널에서 netlink를 통해서 패킷을 처리하는 절차, 패킷이 버퍼링되면서 발생하는 지연 문제, 그 원인을 제공하는 intra-flow interference, inter-flow interference 등에 대해서도 다시 살펴볼 수 있었다.

퀄넷(QualNet) 네트워크 시뮬레이터에서는 메쉬 네트워크 만드는 매뉴얼에 따라서 만들어 놓고 노드 몇번에서 다른 노드 몇번으로 패킷을 몇개 보내라고 시키면 위에 언급된 각종 도구들의 역할을 전혀 몰라도 실험하는 데 아무 이상이 없었고, 성능 측정 결과도 바로바로 나왔다. 그러면 나는 그저 next-hop으로 패킷을 전달하는 부분만 고쳐 가면서 실험해서 그래프를 만들어 내면 되었다.

그러나 현실 세계에서 무선 메쉬 네트워크가 서로 기본적인 "연결" 상태를 유지하도록 만드는 기본적인 것도 호락호락하지 않았고, 여기에 스마트폰이나 노트북을 연결해서 인터넷을 하거나 서로 통신이 되도록 만들기 위해서 이것저것 시도하면서부터는 더더욱 멘붕 상태에 빠져들 수밖에 없었다.

최근 들어서야 여러 앱들을 돌리고 네트워크 상태를 모니터링할 수 있게 되었는데, 이제 실제로 나만의 "라우팅"을 적용할 수 있겠다는 부푼 기대를 안고서 실험을 했으나, 근본적으로 라우팅만 가지고는 해결이 안되는 문제임을 인식한 직후에는 또 한번 절망할 수밖에 없었다. 아, 이래서 내가 저널에 투고한 논문이 reject 되었던 것일까?

------------------- 내가 다시 석사과정 2년차 또는 박사과정 1년차로 돌아간다면, 당장 노트북이든 보드PC든 라우터든 여러 개를 가져와서 실제로 돌아가는 무선 네트워크 실험 환경을 구축하는 것부터 시작할 것이다. 그것이 한 학기가 넘게 걸리든, 거의 일 년이 걸리는 한이 있더라도 반드시 테스트베드 환경 구축을 강행할 것이다. 그렇게 실제로 써먹을 수 있는 테스트베드를 만드는 작업 그 자체가 적어도 나에게는 이론을 동시에 습득하기에 가장 효과적이기 때문이다.

이렇게 무선 네트워크 환경에서 패킷이 머신 하나에 들어오고 나가기까지의 모든 세부 절차에 대한 총체적인 이해를 바탕으로, 그 다음에야 실제로 내가 해결하고 싶은 문제 상황을 상상해 보고, 매일매일 테스트베드 환경에 돌려볼 것이다. 만약 기존 환경에서 잘 해결이 안 된다면, 그것이 최소한의 research goal은 될 수 있다. 하지만 내가 단독으로 그 목표를 해결하면 아무 소용이 없으므로, 이제 기존의 논문들이 어떻게 했는지를 공부해서 그 개념을 실험 환경에 적용해서 돌려볼 것이다. 물론 너무나 당연한 소리지만, 기존 연구는 반드시 최고 수준의 학회/저널에서 최근에 발간된 논문들 중에서 찾을 것이다. 최근에 발간된 최고 수준의 학회/저널에 올라오지 않는 주제라면 사실 조심해야 한다. 모 아니면 도가 될 수 있기 때문이다. 정말로 해결이 필요한 실용적이고 중요한 문제인데 아무도 해결하지 않았거나, 해결할 가치가 없거나(공학적인 의미가 없거나) 둘 중 하나이기 때문이다. 하지만, 전자일 확률을 1%도 안 된다.

그런데 아마 내가 관심있어 하는 가장 최근의 핫한 연구분야는 내가 앞서 '이론의 실제화' 과정에서 구축한 테스트베드에 비해 이미 여러 단계 앞서 있을 것이다. 그리고 이미 어느 정도 오픈소스로 쉽게 구할 수 있게 되어 있을 가능성도 높다. 그럼에도 불구하고 위와 같이 기본적인 테스트베드를 구축하는 연습은 적어도 네트워크 분야에서는 안할 수가 없는 것 같다. 저 과정을 이해하지 못한 채로 신기술을 바로 적용하면 그 내부 작동 원리를 이해하기 위해서 결국 언젠가는 공부해야 하기 때문이다. 물론 최신 기술을 바로 설치해서 써 보는 것부터 시작해서 세부 개념과 원리를 익혀 가는 방법도 결코 나쁘지 않을 것이다. (예를 들면, 요즘 핫한 SDN 도구 중 하나인 OpenFlow나, 그 위에서 작동하는 ONOS 같은 컨트롤러 패키지부터 설치해서 써 보는 것.) 어쨌든 결국 최종적으로 얻게 되는 지식은 다를 바가 없을 테니까. 즉, 성향에 따라서 어느 방법이든 선택해서 열심히 익혀 나가는 수밖에 없다.

비록 많이 늦었지만, 이제서라도 이론을 다시 쌓아올리고, 실제 환경과 습득한 이론 사이의 간극을 줄여 가고 있으므로, 조금 더 노력해서 반드시 의미 있는 연구 결과를 만들어 내고 싶다. 남부끄럽지 않은 박사가 되어야겠다. 


반응형
블로그 이미지

Bryan_

,