Build Tx

• Debian에선 vds_tx, vds_cm 레포지토리를 받고
  • init.py 스크립트로 돌리기만 하면
  • 테스트 환경을 바로 만들 수 있음
• Windows는 vds-cm이 서비스로 등록되어서 동작
  • msi 인스톨러를 설치하는 과정에서
  • vds-cm 프로그램을 서비스로 등록하는 단계가 포함되어 있음

<aside> 💡 개발을 하다보면 매번 msi를 만들어 수정해야하는 건가..?

• msi 설치는 한번만 하고 vds-tx가 위치하는 시스템 폴더의 파일들만 교체해주면 개발을 하면서 테스트해볼 수 있음

  • vds-server 폴더에는 vds_tx, vds_cm 레포에서 init.py를 실행했을 때 만들어지는 빌드 결과물들로 구성이 되어있음
  • init.py 한번돌리고나면 out폴더가 생기고 그 안에 빌드 결과물(vds-tx.exe, vds-cm.exe)들이 모여있음

• init.py에 -install : out 폴더에 있는 빌드 결과물을 시스템 폴더, 일반적인 앱들이 모여있는 곳으로 복사하도록 만들어준다.

  • install : 설치한다 → 파일을 옮기는 행위

• windows는 C 드라이브 밑에 있는 Program Files 폴더가 앱들이 일반적으로 설치되는 경로

• Debian의 경우는 /usr/bin (excutable), /usr/lib (library) 에 설치됨

• msi를 통해 설치한 경로에 있는 파일들을 vds_tx, vds_cm 레포의 out 폴더에 있는 걸로만 변경해주면 코드를 수정했을 때 별도의 msi를 다시 만들어 설치하지 않아도 수정사항을 바로 테스트해볼 수 있음 </aside>

• 로컬 머신 TOS를 RX용으로 사용하고, VM이랑 windows 컴퓨터에 tx, cm을 설치하는게 좋음

• vm 안에 rx를 설치하면 Windows에 설치된 tx가 붙을수 없음

Direct Mode

Standalone Mode (Curtain)

💡 문제가 생겼을땐

log 파일을 확인하자 (Info/Waring/Error/Status)

보통 문제가 생겼을땐 Warning이나 Error를 확인하면 된다.

• 파이프가 끝났다 → 소켓연결 종료
• 시간도 중요한 단서가 될 수 있음

log 파일은 txt 형태가 아닌 xml 형태여야 함