| 지상현 2012-11-18 PM 1:48:18 |
|
|
|
무엇을 어떻게 하시려는지 정확히 모르겠지만, 다음과 같은 환경이라고 가정해봅시다.
컴퓨터: 집컴 (PC1), 회사컴 (PC2), 웹호스팅서버 (서버), 스마트폰(PC3)
원래 제어하고 싶은 컴퓨터끼리 직접 연결하는게 보통이지만 웹호스팅을 활용해야 하기 때문에 중간에 서버를 끼워넣습니다.
시나리오: 집컴에서 회사컴을 제어
PC1 - 서버 - PC2
시나리오: 스마트폰으로 회사컴을 제어
PC3 - 서버 - PC2
등등...
웹호스팅이라고 하셨기 때문에 HTTP와 서버사이드스크립트(PHP나 JSP 등)을 지원할 수 있다고 가정해보면,
'제어하려는 쪽'에서는 명령을 서버에 보내줍니다.
'제어받는 쪽'에서는 서버에서 명령을 받습니다.
즉, 서버는 중간에서 명령을 전달하는 책임을 갖습니다.
이때, HTTP는 요청(Request)를 넘기면 응답(Response)하는 구조로, 제어자 ---> 서버 로의 전달은 단순히 보내면 됩니다만,
서버 ---> 피제어자 로의 전달은 단순히 받기 힘듭니다.
요즘 말하는 push 서비스와 유사한 것으로, HTTP는 push 서비스에 적합하지 않습니다. 따라서 이 경우 피제어자는 서버에게 전달받은 명령이 있는지 polling을 해야 합니다. (쉽게 말해 계속 새로고침을 해야 합니다)
따라서 이런 구조가 됩니다.
제어자 ----- 명령을 전해주세요 -----> 서버
<----- 전달하겠습니다 ------
서버 <------ 전달할 명령이 있나요 ----- 피제어자
------- 여기 있습니다 ----------->
이런 논리로 프로그램을 만든다면, 우선 제어자와 피제어자 쪽에서는 HTTP를 이용하여 서버와 통신할 수 있어야 합니다.
서버쪽에서도 중간에 명령을 받고 다시 전달해줄 수 있는 프로그램이 있어야 하며, 명령이 바로 전달되는 것이 아니므로 중간에 명령을 어느 정도 보관하고 있도록 해야 합니다. (이메일 주고 받는 것과 똑같습니다)
서버 설정에 따라 다르지만, 만약 서버에서 지속적인 TCP/IP 연결 가능한 소켓을 만들 수 있도록 설정되어 있다면, 서버에서는 프록시 개념으로 제어자가 피제어자에게 직접 명령을 전달할 수 있겠지만, 보통 웹호스팅은 그렇게 되어 있지 않습니다. |
|
