KR20160051794A

KR20160051794A - 전자 장치 및 전자 장치의 제어 방법

Info

Publication number: KR20160051794A
Application number: KR1020167007221A
Authority: KR
Inventors: 강동현; 양승률; 문경수; 김진필
Original assignee: 엘지전자 주식회사
Priority date: 2013-11-04
Filing date: 2014-11-04
Publication date: 2016-05-11
Also published as: JP2017502373A; WO2015065149A1; JP6301464B2; KR101898492B1; US10367864B2; EP3068139A4; CN105706455A; US10819761B2; EP3068139B1; CN105706455B; US20160241614A1; US20190334966A1; EP3068139A1

Abstract

전자 장치 및 전자 장치의 제어 방법이 개시된다. 전자 장치는 어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부, 컴패니언 장치와 데이터를 송수신하는 통신부를 포함하며, 어플리케이션 프로세서는 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결한다.

Description

전자 장치 및 전자 장치의 제어 방법{ELECTRONIC DEVICE AND METHOD FOR CONTROLLING ELECTRONIC DEVICE}

본 명세서는 전자 장치 및 전자 장치의 제어 방법에 관한 것이다.

방송 및 통신 기술의 발전에 따라 다양한 방송 장치 및 방송 서비스에 대한 기술이 개발되고 있다. 최근 스마트 폰과 스마트 TV가 대중화되어 다양한 어플리케이션이 스마트 폰과 스마트 TV 상에서 실행될 수 있다. 하나의 어플리케이션이 스마트 폰에서 실행되고 있을 때, 사용자는 스마트 TV에서도 스마트 폰에서 실행 중인 어플리케이션을 실행하고자 하는 경우가 있다. 이 경우 일반적으로 사용자는 정해진 경로를 따라 스마트 TV를 조작하여 스마트 폰에서 실행 중인 어플리케이션을 실행시킬 수 있다. 최근 통신 환경에서, 자신이 사용 중인 어플리케이션을 다른 기기에서 실행 중인 어플리케이션과 통신을 하고자 하는 사용자의 요구가 증가하고 있다. 그러나, 상술한 바와 같이 별도로 스마트 TV를 조작하여 어플리케이션을 실행시키는 것은 불편함이 있다.

이러한 불편함을 해결하기 위해 한 기기의 어플리케이션에서 다른 기기의 어플리케이션으로 통신을 수행할 수 있는 기술에 대한 필요성이 있다.

본 명세서의 목적은 하나의 전자 장치의 어플리케이션을 다른 전자 장치의 어플리케이션과 통신을 할 수 있는 전자 장치 및 전자 장치의 제어 방법을 제공하는 것이다.

본 명세서의 일 실시 예에 따르면, 전자 장치는 어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부, 상기 컴패니언 장치와 데이터를 송수신하는 통신부를 포함하며, 상기 어플리케이션 프로세서는 상기 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결할 수 있다.

그리고, 상기 네트워크 프로세서는 웹소켓 서버일 수 있다.

또한, 상기 어플리케이션 프로세서는 상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 네트워크 프로세서로 전송할 수 있다.

또한, 상기 네트워크 프로세서는 상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키고, 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 컴패니언 장치의 스트림 헤드를 생성하고, 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결할 수 있다.

그리고, 상기 네트워크 프로세서는 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거할 수 있다.

그리고, 상기 어플리케이션 프로세서는 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송할 수 있다.

또한, 상기 네트워크 프로세서는 상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결할 수 있다.

본 명세서의 일 실시 예에 따르면, 전자 장치의 제어 방법은 컴패니언 장치와 연결하는 단계 및 상기 컴패니언 장치와 데이터를 송수신하는 단계를 포함하며, 상기 연결하는 단계는 상기 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결할 수 있다.

그리고, 상기 네트워크 프로세서는 웹소켓 서버일 수 있다.

그리고, 전자 장치의 제어 방법은 상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 어플리케이션 프로세서가 상기 네트워크 프로세서로 전송하는 단계를 더 포함할 수 있다.

또한, 전자 장치의 제어 방법은 상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 네트워크 프로세서가 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키는 단계 및 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 네트워크 프로세서가 상기 컴패니언 장치의 스트림 헤드를 생성하여 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 단계를 더 포함할 수 있다.

또한, 전자 장치의 제어 방법은 상기 네트워크 프로세서가 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 단계를 더 포함할 수 있다.

또한, 전자 장치의 제어 방법은 상기 어플리케이션 프로세서가 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 단계를 더 포함할 수 있다.

한편, 상기 연결하는 단계는 상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결할 수 있다.

본 명세서의 다양한 실시 예에 따르면, 전자 장치 및 제어 방법은 하나의 전자 장치에서 실행 중인 어플리케이션과 다른 전자 장치에서 실행 중인 어플리케이션 간의 통신을 수행할 수 있다.

그리고, 전자 장치 및 제어 방법은 하나의 전자 장치와 다른 전자 장치 간의 통신을 위해 웹소켓 서버를 사용하여 인터페이싱할 수 있다.

또한, 전자 장치 및 제어 방법은 하나의 전자 장치와 다른 전자 장치를 1:1로 연결시켜 줄 수 있다.

도 1은 일 실시 예에 따른 전자 장치의 블록도.
도 2는 일 실시 예에 따른 제1 클라이언트의 연결을 설명하는 도면.
도 3은 일 실시 예에 따른 제2 클라이언트의 연결을 설명하는 도면.
도 4는 일 실시 예에 따른 제1 및 제2 클라이언트 간의 연결을 설명하는 도면.
도 5는 일 실시 예에 따른 추가 연결 요청을 설명하는 도면.
도 6은 일 실시 예에 따른 IP 어드레스가 없는 경우 클라이언트 간의 연결을 설명하는 도면.
도 7은 일 실시 예에 따른 어플리케이션 간의 연결을 위한 대기 연결을 설명하는 도면.
도 8은 일 실시 예에 따른 제2 클라이언트와 연결을 위한 새로운 연결 요청을 설명하는 도면.
도 9는 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 클라이언트의 설정을 설명하는 도면.
도 10은 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 및 제2 클라이언트의 설정을 설명하는 도면.
도 11은 IP 어드레스를 포함하는 경우 복수의 제2 클라이언트에 연결하는 일 실시 예를 설명하는 도면.
도 12는 일 실시 예에 따른 전자 장치의 제어 방법의 흐름도.

발명의 실시를 위한 최선의 형태

이하 상술한 목적을 구체적으로 실현할 수 있는 본 명세서의 바람직한 실시 예를 첨부한 도면을 참조하여 설명한다. 이때 도면에 도시되고 또 이것에 의해서 설명되는 본 명세서의 구성과 작용은 적어도 하나의 실시 예로서 설명되는 것이며, 이것에 의해서 본 명세서의 기술적 사상과 그 핵심 구성 및 작용이 제한되지는 않는다.

본 명세서에서 사용되는 용어는 본 명세서에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당해 기술 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 명세서의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 본 명세서의 전반에 걸친 내용을 토대로 정의되어야 함을 밝혀두고자 한다.

도 1은 일 실시 예에 따른 전자 장치의 블록도이다.

도 1을 참조하면, 전자 장치(100)는 제어부(110) 및 통신부(120)를 포함할 수 있다. 제어부(110)는 컴패니언 장치와 통신 연결을 수행할 수 있다. 그리고, 컴패니언 장치와 통신 연결이 되면 통신부(120)는 컴패니언 장치와 데이터를 송수신할 수 있다.

그리고, 제어부(110)는 네트워크 프로세서(111) 및 어플리케이션 프로세서(112)를 포함할 수 있다. 어플리케이션 프로세서(112)는 네트워크 프로세서(111)로 컴패니언 장치와 연결을 요청할 수 있다.

네트워크 프로세서(111)는 어플리케이션 프로세서(112)로 받은 연결 요청을 대기 상태로 둘 수 있다. 네트워크 프로세서(111)는 아직 컴패니언 장치와 연결이 되지 않았기 때문이다. 이후에 네트워크 프로세서(111)는 컴패니언 장치로부터 연결 요청을 수신할 수 있다. 네트워크 프로세서(111)는 컴패니언 장치로부터 수신한 정보를 기초로 매칭되는 어플리케이션 프로세서(112)의 연결 요청을 검색할 수 있다. 네트워크 프로세서(111)는 매칭되는 연결 요청을 검색하면 컴패니언 장치와 어플리케이션 프로세서(112)를 연결할 수 있다.

일 실시 예로서, 어플리케이션 프로세서(112)는 어플리케이션 모듈, 어플리케이션 브라우저일 수 있다. 또는, HbbTV 어플리케이션일 수 있다. 일 실시 예로서, 네트워크 프로세서(111)는 네트워크 모듈로 구현될 수 있다. 또는, 네트워크 프로세서(111)는 웹소켓 서버(WebSocket Server)일 수 있다. 네트워크 프로세서(111)는 어플리케이션 프로세서(112)와 컴패니언 장치를 연결해 줄 수 있다. 일 실시 예로서, 네트워크 프로세서(111)가 웹소켓 서버로 구현되는 경우, 어플리케이션 프로세서(112)와 컴패니언 장치는 각각 하나의 클라이언트라고 볼 수 있다. 다시 말해서, 웹소켓 서버가 제1 클라이언트와 제2 클라이언트를 연결해 줄 수 있다. 또는, 제1 클라이언트와 제2 클라이언트를 각각 피어(peer)라고 부를 수도 있다. 경우에 따라, 웹소켓 서버는 전자 장치 외부에 별도의 장치로서 구현될 수도 있다.

한편, 어플리케이션 프로세서(112)는 하나의 어플리케이션을 구동시킬 수 있다. 그리고, 컴패니언 장치도 하나의 어플리케이션을 구동시킬 수 있다. 어플리케이션 프로세서(112)는 네트워크 프로세서(111)를 통해 컴패니언 장치와 연결할 수 있다. 컴패니언 장치는 어플리케이션 프로세서(112)로부터 데이터를 수신하여 어플리케이션 프로세서(112)가 구동 중인 어플리케이션을 수신하여 구동시킬 수 있다. 또는, 어플리케이션 프로세서(112)와 컴패니언 장치는 각각 어플리케이션을 구동시킬 수 있다. 어플리케이션 프로세서(112)는 컴패니언 장치와 연결하여 컴패니언 장치와 데이터를 송수신할 수 있다. 이 경우, 전자 장치(100)와 컴패니언 장치는 어플리케이션 간 통신을 수행한다고 말할 수 있다.

웹소켓 서버는 중계기로 이용되고 어플리케이션 간의 통신 채널을 생성할 수 있다. 생성된 통신 채널은 전자 장치(100)와 컴패니언 장치 간 통신을 가능하게 할 수 있다. 웹소켓 서버는 통신 채널을 생성하기 위해 통신을 하고자 하는 어플리케이션 네임 아이디(application name id)와 어플리케이션 오리진 아이디(application origin id)를 이용하여 같은 정보를 요청하는 어플리케이션끼리 채널을 연결해 줄 수 있다. 일 실시 예로서, 상술한 방법은 HbbTV 2.0에서 웹소켓 API를 수정하지 않고 어플리케이션(클라이언트)와 어플리케이션(클라이언트)을 연결할 수 있다.

본 명세서에서는 각 용어를 혼용하여 사용하도록 한다.

도 2는 일 실시 예에 따른 제1 클라이언트의 연결을 설명하는 도면이다.

도 2를 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 일 실시 예로서, 어플리케이션 프로세서는 HbbTV 어플리케이션 또는 제1 클라이언트일 수 있고, 네트워크 프로세서는 HbbTV 웹소켓 서버일 수 있다. 컴패니언 장치(200a)는 컴패니언 장치 프로세서를 포함할 수 있다. 일 실시 예로서, 컴패니언 장치 프로세서는 컴패니언 어플리케이션 또는 제2 클라이언트일 수 있다. 클라이언트 간의 연결을 수행하기 위해 웹소켓 서버는 변경이 필요할 수 있다. 아래에서는 웹소켓 서버의 변경과 관련된 동작을 설명한다. 변경된 웹소켓 서버는 HbbTV 2.0 TV에서 구동될 수 있다.

일반적으로 웹소켓 클라이언트는 연결을 하고자하는 원격 호스트 및 웹소켓 연결 업그레이드 헤더와 함께 초기 GET 요청시 그 호스트에서 원하는 서비스를 위한 상대적 URI를 지정할 수 있다. 그러나, HbbTV의 경우, 통신 연결을 위한 피어(peer)(예, 컴패니언 장치)가 아직 웹소켓 서버와 컨택되지 않을 수 있다. 따라서, 클라이언트 간 연결을 위한 제1 클라이언트로부터의 연결 요청은 대상 피어의 연결 요청이 있을 때까지 활성을 유지할 필요가 있다.

이러한 필요성 때문에 업그레이드 웹소켓 프로토콜 GET 요청은 특정 사용을 정의한 두 가지 필드를 포함할 수 있다. URI 요청(Request-URI)은 일반 접두사 스트링의 기 설정된 포맷을 가질 수 있다. 이 필드는 대응되는 통신 피어들을 매칭하는데 사용될 수 있다. 호스트 요청 헤더(Host request-header) 필드는 웹소켓 서버에서 동작하는 TV 셋을 언급(매칭 URI 요청을 가진 임의의 피어와 통신이 설립되는 경우)하거나 특정 컴패니언 장치를 언급(지정된 장치 및 매칭 URI 요청과 통신이 설립되는 경우)할 수 있다. 즉, 어플리케이션 프로세서는 네트워크 프로세서에서 동작하는 전자 장치 정보 또는 컴패니언 장치 정보를 나타내는 호스트 요청 헤더 정보를 네트워크 프로세서로 보낼 수 있다.

URI 요청을 위한 포맷은 아래의 ABNF 문법에 따를 수 있다.

HbbTV-Request-URI = "/hbbtv/" org-id "." app-id

org-id = 8HEX

app-id = 4HEX

URI 요청에 대응하여 웹소켓 서버는 스트림 헤드를 생성해야 하는데, 이것은 클라이언트에 의해 업그레이드 GET 요청에서 지원되는 URI 요청과 관련된 하프(half) 오픈 연결을 의미할 수 있다. 웹소켓 서버는 웹소켓 프로토콜 핸드쉐이크(handshake) 응답에 즉시 응답하는 대신, 다른 피어(peer)가 나타나길 기다리면서 제1 클라이언트의 대기 상태를 유지시킬 수 있다. 웹소켓 서버가 종료하길 희망하는 경우, 서버는 504 게이트웨이 타임아웃 응답(504 Gateway Timeout response)으로 반응할 수 있다.

클라이언트 간 연결을 요청할 때, 클라이언트는 Sec-웹소켓 프로토콜 헤더를 사용하지 않을 수 있다. 서버는 클라이언트 간 연결을 위한 요청 내의 Sec-웹소켓 프로토콜 헤더를 무시할 수도 있다. 클라이언트 간 연결 요청 내의 호스트 헤더 필드는 서버가 어태치(attached)되는 로컬 서브 네트워크 상의 어떤 장치도 지정하지 않으면, 서버는 403 금지 응답(403 Forbidden response)으로 반응할 수 있다. 모든 HbbTV 2.0 웹소켓 클라이언트는 HbbTV 2.0 웹소켓 서버로부터 클라이언트 간 연결을 요청하는 메소드를 사용할 수 있다.

In other words, usually, a WebSocket client would specify the remote host to which it wishes a connection to be established, and the relative URI for the desired service on that host in the initial GET request along with the WebSocket connection upgrade header. In the HbbTV case however, it can not be assumed that the peer to which communications are to be established, has contacted the WebSocket server yet. A connection request from a client in the special client-to-client mode, hence needs to be kept active until another, suitable peer arrives.

To achieve this, we define special uses for two fields of the WebSocket protocol upgrade GET request.

The Request-URI - which is part of the Request-Line - takes a predefined format with a common prefix string. This field is used to match corresponding communication peers.

The Host request-header field shall either refer to the TV set running the WebSocket server (in which case communications with any peer with a matching Request-URI will be established), or to a specific companion device (in which case communications only with the designated device, and with a matching Request-URI will be established).

The format for the Request-URI field shall be according to the following ABNF grammar:

HbbTV-Request-URI = "/hbbtv/" org-id "." app-id

org-id = 8HEX

app-id = 4HEX

These rules are illustrated in Fig. 2. In response to such a request, an HbbTV WebSocket server shall create a stream head, that is a half open connection, which is associated with the Request-URI supplied in the upgrade GET request by the client. The server shall not respond immediately with a WebSocket Protocol Handshake response, but instead wait for other peers to appear, and thereby keep the first client waiting. In case the server wishes to implement a time-out, it shall respond with a 504 Gateway Timeout response.

Clients shall not use the Sec-WebSocket-Protocol header when requesting client-to-client connections. Servers may ignore the Sec-WebSocket-Protocol header in requests for client-to-client connections. Servers shall respond with a 403 Forbidden response if the Host header field in a client-to-client connection request does not specify a device on any of the local sub-networks that the server is attached to. All HbbTV 2.0 WebSocket clients shall use the method described in this section to request client-to-client connections from HbbTV 2.0 WebSocket servers.

도 3은 일 실시 예에 따른 제2 클라이언트의 연결을 설명하는 도면이다.

도 3을 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 네트워크 프로세서(예, 웹소켓 서버)는 HbbTV 어플리케이션 및 컴패니언 어플리케이션으로부터 연결 요청을 수신할 수 있다.

다른 클라이언트가 상술한 메소드를 이용하여 클라이언트 간 연결을 요청할 때, 서버는 도 3에서 보는 바와 같이 새로운 요청을 위한 스트림 헤드를 생성할 수 있다. 새로운 스트림 헤드가 생성된 후, 서버는 URI 요청 및 새로 생성된 스트림 헤드외 매칭되는 호스트 헤더 필드 값을 위해 현재 연결 대기 중인 스트림 헤드의 집합을 검색할 수 있다. 어떠한 매칭도 발견되지 않으면 서버는 새로 생성된 스트림 헤드를 연결을 위해 대기 중인 스트림 헤드의 집합에 추가하고, 추가적인 클라이언트 간 연결 요청을 기다릴 수 있다.

In other words, when another client requests a client-to-client connection using the method as above, the server shall also create a stream head for that new request as shown in Fig. 3. After a new stream head is created, the server shall search the collection of stream heads currently waiting to be connected, for Request-URI and Host header field values matching those of the newly created stream head. If no match is found, the server shall add the newly created stream head to the collection of stream heads currently waiting to be connected, and shall keep waiting for further client-to-client connection requests.

도 4는 일 실시 예에 따른 제1 및 제2 클라이언트 간의 연결을 설명하는 도면이다.

도 4를 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 네트워크 프로세서(예, 웹소켓 서버)는 HbbTV 어플리케이션 및 컴패니언 어플리케이션을 연결할 수 있다.

새로 생성된 스트림 헤드가 현재 연결을 위해 대기하는 스트림 헤드의 집합 내의 스트림 헤드로서 동일한 호스트 헤더 필드 값 및 동일한 URI 요청(Request-URI)과 연관되어 있다면, 웹소켓 서버는 그 집합으로부터 매칭되는 스트림 헤드를 제거하고, 두 개의 스트림 헤드 사이의 양 방향 통신 채널을 설립할 수 있다.

두 개의 스트림 헤드가 연결되면, 서버는 즉시 하나의 스트림 헤드로부터 수신한 모든 데이터를 출력하고, 각각 다른 스트림 헤드로 변경하지 않는다. 이렇게 함으로써, 두 클라이언트 간의 투명한 통신 채널(a transparent communications channel)이 설립될 수 있다.

두 클라이언트 중 하나가 클로즈 프레임(Close frame)을 전송하면, 서버는 다른 클라이언트에게 대응되는 클로즈 프레임을 전송할 수 있다. 두 클라이언트 중 하나가 클로즈 프레임을 전송하지 않고 연결을 해제하면, 서버는 클로즈 프레임을 생성하고 다른 클라이언트에게 전송할 수 있다.

즉, 네트워크 프로세서는 어플리케이션 프로세서의 연결 요청이 있을 때, 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시킬 수 있다. 그리고, 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 컴패니언 장치의 스트림 헤드를 생성하여 매칭되는 스트림 헤드의 존재 여부를 검색할 수 있다. 매칭되는 스트림 헤드가 존재하면, 네트워크 프로세서는 스트림 헤드 그룹으로부터 매칭되는 어플리케이션 프로세서의 스트림 헤드와 컴패니언 장치의 스트림 헤드를 연결할 수 있다. 이때, 네트워크 프로세서는 매칭된 어플리케이션 프로세서의 스트림 헤드 또는 컴패니언 장치의 스트림 헤드를 스트림 헤드 그룹으로부터 제거할 수 있다.

In other words, if a newly created stream head is associated with the same Request-URI and Host header field values as a stream head in the collection of stream heads currently waiting to be connected, the server shall remove the matching stream head from the collection, and shall establish a full-duplex communications channel between the two stream heads as shown in Fig. 4. Once the two stream heads are connected, the server output all data received from one stream head immediately and unaltered to the respective other stream head. Thereby, a transparent communications channel is established between the two clients. If one of the two clients sends a Close frame, the server shall send a corresponding Close frame to the other client. If one of the two clients disconnects without sending a Close frame, the server shall generate a Close frame, and shall send it to the other client.

도 5는 일 실시 예에 따른 추가 연결 요청을 설명하는 도면이다.

도 5를 참조하면, HbbTV 어플리케이션(클라이언트)은 컴패니언 장치(200a)의 컴패니언 어플리케이션(클라이언트)과 연결되어 있다. 그리고, HbbTV 어플리케이션은 다른 클라이언트를 위한 다른 스트림 헤드를 생성할 수 있다. HbbTV 어플리케이션은 다른 어플리케이션과 추가로 연결될 수 있다. 스트림 헤드는 클라이언트 간의 연결을 설립 전에 연결 가능한 스트림 헤드 집합에서 제거되기 때문에 클라이언트 간의 연결은 일대일로 될 수 있다. 만일 클라이언트가 하나 이상의 다른 클라이언트와 통신을 원하면, 클라이언트는 처리 가능한 클라이언트 간의 연결 최대 갯수에 다다를 때까지 추가 연결 요청을 서버로 보낼 수 있다.

웹소켓 서버는 연결을 위해 대기하는 스트림 헤드 집합 상에서 동일한 URI 요청과 호스트를 가진 동일한 클라이언트를 위한 하나 이상의 스트림 헤드를 허락하지 않는다. 클라이언트가 하나의 성공적인 연결이나 타임 아웃 전에 동일한 URI 요청 및 호스트를 가진 다른 클라이언트와의 연결 요청을 발행하면, 서버는 403 금지 응답(403 Forbidden response)으로 반응할 수 있다.

클라이언트는 연결될 대기 상태에서 몇 가지 서로 다른 URI 요청/호스트 조합의 클라이언트 간의 연결 요청을 가질 수 있다. 클라이언트는 하나가 성공적으로 연결되거나 타임 아웃되기 전에 동일한 URI 요청/호스트 조합을 가지고 다른 클라이언트와의 연결을 요청하는 시도를 할 수 없다.

In other words, any stream head be removed from the collection of stream heads available for connecting, prior to establishing a client-to-client connection, such client-to-client connections are one-to-one only. If a client wishes to communicate to more than one other client, it shall issue further connection requests to the server until the maximum number of client-to-client connections it is able to process, has been reached. Servers shall not allow more than one stream heads for the same client with the same Request-URI and Host to be on the collection of stream heads currently waiting to be connected. If a client issues another client-to-client connection request with the same Request-URI and Host, before the previous one has been successfully connected or has timed-out, the server shall respond with a 403 Forbidden response. Clients may have several client-to-client connection requests with different Request-URI/Host combinations in the waiting to be connected state. Clients shall not attempt to request another client-to-client connection with the same Request-URI/Host combination, before the previous one was either successfully connected or has timed-out.

다른 것과 함께 수행되고 표준 웹소켓 서버 기능들을 사용하며 그들 간의 간섭이 없도록 하기 위해 특정 장치간 동작으로서 URI 요청을 위한 /hbbtv/orgid.appid 스킴(scheme)이 사용될 수 있다. URI 요청 및 호스트 헤더 필드의 매칭은 두 가지 접근 방법을 허용할 수 있다. 첫째, 특정 장치(클라이언트)가 호스트 헤더에 의해 타겟되면, 클라이언트는 그 타켓된 특정 클라이언트와 대화를 희망할 수 있다. 그것은 다른 수단(예, UPnP의 파트로서 SSDP)을 통해 그것의 존재에 대해 인식될 수 있다. 둘째, 호스트 헤더 필드가 서버를 타켓으로 한다면, 동일한 서버를 타켓팅하는 모든 클라이언트에게 동일할 수 있다. 이것은 URI 요청만이 적절한 통신 피어를 선택하기 위한 차별적인 요소임을 나타낸다. 이렇게 호스트 헤더 필드에서 효과적으로 서버를 타켓팅하는 것은 동일한 URI 요청을 사용하고 서버를 타켓팅하는 다른 클라이언트와 매칭되는 와일드카드를 제공할 수 있다. 전용적이고 기회적인 연결 설립 전략이 가능할 수 있다.

In other words, we chose the special "/hbbtv/orgid.appid" scheme for the Request-URI as an escape into the special server client-to-client behaviour in order to allow it to be implemented along with other, standard WebSocket server functionalities, and without interfering with them. The choice of matching the Request-URI and Host header field allows for two approaches: if a specific device is targeted by the Host header, the client only wishes to talk to that specific other client. It may have learnt about its existence through other means (e.g. SSDP as part of UPnP). Secondly, if the Host header field targets the server, it will be the same for all clients targeting the same server. This will result in only the Request-URI being the discriminating factor for choosing suitable communication peers. Hence, targeting the server in the Host header field effectively provides a wildcard match with any other client using the same Request-URI and also targeting the server. So both, dedicated and opportunistic connection establishment strategies are possible.

HbbTV 2.0 웹소켓 서버는 어떤 인증, 허가 또는 확인 과정을 수행하지 않기 때문에 클라이언트 간 연결이나 클라이언트와 웹 소켓 서버간의 신뢰성이 없을 수 있다. 개인 정보 또는 웹소켓 서버를 통한 민감한 정보를 교환하려는 클라이언트는 통신 프라이버시를 보증할 끝단 암호를 수행할 수 있다. 클라이언트는 웹소켓 서버를 통해 통신을 수행할 피어의 신원이나 진위를 설립할 암호화 방식을 수행할 수 있다. HbbTV 2.0 웹소켓 서버는 연결된 인터넷을 통해 표시된 클라이언트와 연결을 설립하기 때문에 HbbTV 웹소켓 서버를 통해 다른 클라이언트에 대한 성공적인 서비스 거부 공격(denial-of-service attack)을 받지 않을 수 있다. 공격받는 클라이언트는 서버에게 다른 클라이언트로 연결하라는 요청을 중지할 수 있다.

서버는 아직 연결되지 않은 URI 연결/호스트 컴비네이션에 동시 연결 시도를 거절하는 것으로 정의했기 때문에 서비스 거부 공격은 서버 자체에 대해 시도될 수도 있다. 이것은 에러 응답이 생성되도록 동일한 연결 요청을 반복적으로 전송하거나 많은 오픈 스트림 헤드를 생성하여 서버의 리소스를 소비하기 위한 하나의 시도로서 랜덤 연결 요청을 전송함으로써 행해질 수 있다. 두 기술은 HTTP 서버에 대한 일반적인 전략이고, 웹소켓이나 HbbTV 사용의 특정한 것은 아니다. 어떤 웹소켓 서버 실행은 적절한 경감 구조를 가질 수 있다. (예, 응답 전송이나 스트림 헤드의 생성을 중지시킴으로써)

In other words, since the HbbTV 2.0 WebSocket server does not perform any authentication, authorisation, or other verification, no trust can be associated with client-to-client connections, or between clients and WebSocket servers. Clients that wish to exchange private, or otherwise sensitive information through a WebSocket server should therefore employ end-to-end encryption to ensure the privacy of the communication. Likewise, such clients should employ cryptographic methods to establish the identity and authenticity of any communication peers to which they wish to communicate through a WebSocket server. Since an HbbTV 2.0 WebSocket server will establish connections only to clients who have indicated the intent of being connected, it is very unlikely that a successful denial-of-service attack could be staged against another client through an HbbTV WebSocket server. The client under attack can simply stop asking the server to be connected to other clients.

Since we defined that a server shall reject simultaneous connection attempts to a not yet connected Request-URI/Host combination, a denial-of-service attack might be attempted against the server itself. This could be done by repeatedly sending the same connection request to provoke error responses being generated, or by sending random connection requests in an attempt to exhaust the server's resources by creating many open stream heads. Both techniques are general strategies against HTTP servers, and are not specific to WebSocket or HbbTV use of it. We hence expect that any WebSocket server implementation (be it of the HbbTV flavour or not) will have suitable mitigation mechanisms (e.g. by stopping sending responses or creating stream heads).

도 6은 일 실시 예에 따른 IP 어드레스가 없는 경우 클라이언트 간의 연결을 설명하는 도면이다.

도 6을 참조하면, 클러이언트 간 통신 연결을 수행하는 방법이 도시되어 있다. 상술한 웹소켓 기반 어플리케이션 간 통신 방법은 웹 소켓 서버가 URI의 경로(호스트 네임을 제외한 나머지 경로, 즉 path)가 같은 어플리케이션끼리 연결시켜 어플리케이션 간 통신을 가능하게 할 수 있다. 클라이언트 간 통신은 전자 장치에서 구동되는 어플리케이션(예, TV 어플리케이션)과 컴패니언 장치에서 구동되는 어플리케이션(CS 어플리케이션)을 구분하여 선택적으로 어플리케이션 간 통신을 수행할 수 있다.

일 실시 예로서, HbbTV에 있어서 URI 요청(Request-URI)은 IP 어드레스를 포함하지 않고 구성할 수 있다. URI의 경로(path)는 루트("/")뒤에 HbbTV를 알리는 예약어("hbbtv")로 시작하고, 그 뒤에 기관 또는 회사 구분자(org-id)와 앱 구분자(app-id)로 구성될 수 있다. 웹소켓 서버(네트워크 프로세서)는 웹소켓 API 콜의 URI 경로가 같은 어플리케이션끼리 연결시켜 줄 수 있다.

신택스) GET "/hbbtv/"org-id"."app-id

실시예) GET/hbbtv/org.mychannel.myapp

한편, 연결을 요청하는 각 클라이언트는 같은 포트(port)를 사용할 수 있고 다른 포트를 사용할 수 있다. 클라이언트들이 같은 포트를 사용하는 경우, 웹소켓 API를 호출하는 어플리케이션의 IP가 같은 경우, 웹소켓 서버는 호출하는 어플리케이션이 HbbTV 어플리케이션임을 알 수 있고, IP가 다른 경우 컴패니언 장치 어플리케이션임을 알 수 있다. 같은 포트를 사용하는 경우, 웹소켓 서버는 서버 실행과 테스트를 간소화할 수 있고, 디스커버리가 불필요한 장점이 있다. (With most WebSocket libraries, need to start a different instance per port. Single port drastically simplifies server implementation and test. No discovery needed if app-2-app server listens on well-defined port on the TV.)

다음으로 클라이언트들이 다른 포트를 사용하는 경우를 설명한다. 이 경우에는 TV에서 구동하는 어플리케이션과 컴패니언 장치에서 구동하는 어플리케이션이 같은 URI 경로를 사용하지만, 서로 다른 포트를 쓰는 경우를 의미한다. 일 실시 예로서, TV에서 구동하는 HbbTV 어플리케이션은 8900 포트를 사용하고, 컴패니언 장치에서 구동하는 어플리케이션은 8901 포트를 사용할 수 있다. 웹소켓 서버가 TV 어플리케이션/컴패니언 어플리케이션이 사용하는 포트를 알면 TV 어플리케이션/컴패니언 어플리케이션 간 통신, 컴패니언 어플리케이션/컴패니언 어플리케이션 간 통신을 구분할 수 있다. 다른 포트를 사용할 때, 서로 같은 호스트 요청-헤더를 사용하여 여러 개의 컴패니언 장치가 TV로 연결될 경우, 이를 구분하여 클라이언트 간을 용이하게 연결할 수 있다. TV와 컴패니언 장치 모두가 호스트 요청-헤더는 같지만 웹소켓 서버에 서로 다른 포트를 통해 접속하여 통신하기 때문에 어느 장치가 컴패니언 장치인지 TV인지 알 수 있다. 이에 따라, 보안 측면에서 보완할 수 있다.

도 7은 일 실시 예에 따른 어플리케이션 간의 연결을 위한 대기 연결을 설명하는 도면이다.

도 7을 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)의 TV 어플리케이션은 웹 소켓 서버로 연결 요청을 전송할 수 있다. TV 어플리케이션은 전자 장치 내에 포함되어 있으므로 웹소켓 서버는 TV 어플리케이션을 로컬 어플리케이션으로 인식할 수 있다. 그리고, 컴패니언 어플리케이션은 전자 장치 외부에 존재하므로 웹소켓 서버는 컴패니언 어플리케이션을 원결 어플리케이션으로 인식할 수 있다. 일 실시 예로서, 어플리케이션은 연결 요청을 할 때 다음과 같은 메소드를 사용할 수 있다.

일 실시 예로서, 네트워크 프로세서는 W3C 웹소켓 API를 실행할 수 있고 최소 200개의 동시 웹소켓 연결을 지원할 수 있다.

네트워크 프로세서는 웹소켓 프로토콜 사양의 서버 측에서 실행하는 두 가지 서비스 엔드 포인트를 제공할 수 있다. 로컬 엔드 포인트는 HbbTV 어플리케이션에 의해 네트워크 프로세서로의 연결을 위한 것이다. 원격 엔드 포인트는 다른 장치의 어플리케이션에 의해 홈 네트워크에 연결될 수 있고, 다른 HbbTV 장치에서 구동하는 원격 컴패니언 어플리케이션 또는 HbbTV 어플리케이션을 포함하기 위한 것이다. HbbTV 어플리케이션은 그들이 동작하는 네트워크 프로세서의 로컬 서비스 엔드 포인트나 동일한 홈 네트워크 상의 다른 하이브리드 터미널의 원격 서비스 엔드 포인트에 연결될 수 있다. 네트워크 프로세서는 홈 네트워크 내의 다른 장치의 로컬 서비스 엔드 포인트에 연결하지 않는 편이 낫다. 예를 들어, 네트워크 프로세서의 로컬 루프백 인터페이스의 로컬 서비스 엔드 포인트를 위치시킴으로써 이룰 수 있다. 다른 서비스 엔드 포인트가 웹소켓 프로토콜 사양의 서버 측을 실행하고 HbbTV 어플리케이션이나 컴패니언 어플리케이션이 그러한 서비스 엔드 포인트를 사용하면 하이브리드 터미널은 다른 서비스 엔드 포인트로서 동일한 호스트 및 포트 조합에서 서비스 엔드 포인트를 위치시키서는 안 된다.

어플리케이션 간 서비스 엔드 포인트를 위한 기본 URL은 웹소켓 URL일 수 있다. 웹소켓 URL은 호스트, 포트, 보안 및 서비스 엔드 포인트의 리소스 네임을 정의할 수 있다. 클라이언트는 서비스 엔드 포인트의 웹소켓 URL에 의해 명시된 호스트와 포트에 연결해야 한다. 클라이언트에 의해 최초 프로토콜 요청에서 사용되는 리소스 네임은 ABNF 문법에 따른다.

resource-name = base-url-resource-name app-endpoint

base-url-resource-name은 서비스 엔드 포인트의 웹소켓 URL으로부터 도출된 리소스 네임이다. app-endpoint는 어플리케이션 사양이다. 이것은 클라이언트로부터 대응되는 클라이언트의 연결 매칭 프로세스에 사용될 수 있다. 대응되는 클라이언트의 메시지는 웹 소켓 프로토콜을 통해 전달될 수 있다. app-endpoint는 충돌을 피하기 위해 어플리케이션 디벨로퍼에 의해 선택될 수 있다. 따라서 app-endpoint는 HbbTV 어플리케이션 또는 컴패니언 어플리케이션 및 그것의 디벨로퍼와 독특하게 연관된 리버스 DNS 표기로 형식화된 식별자로 시작할 수 있다. 하이브리드 터미널은 최소 1000 문자의 길이와 웹 소켓 프로토콜 사양에 의해 리소스 네임에서 허용된 어떤 문자를 포함하는 app-endpoint를 지원할 수 있다.

서비스 엔드 포인트는 클라이언트로부터 최소 10개의 동시 TCP 소켓 연결을 지원할 수 있다. 클라이언트가 서버와 TCP 소켓 연결을 오픈하기 위해 노력할 때, 서버는 서버가 동시 연결을 다룰 수 없으면 요청을 거절할 수 있다. 그렇지 않으면, 서버는 TCP 소켓 연결을 승인하고, TCP 소켓 연결을 웹소켓 프로토콜 핸드쉐이크를 시작할 수 있다. 서버는 클라이언트 요청 핸드쉐이크를 수신하지만 서버는 핸드쉐이크 응답으로 즉시 응답하지 않을 수 있다. 대신 서버는 연결이 페어링될 때까지 또는 클라이언트의 연결이 해제될 때까지 기다릴 수 있다. 이 상태에서 연결은 대기 연결을 구성할 수 있다. 서버가 타임 아웃을 실행하려는 경우, 서버는 504 게이트웨이 타임아웃 응답으로 반응할 수 있다.

서버는 클라이언트에 의해 전송된 요청 핸드쉐이크의 어떤 오리진(origin) 헤더를 무시할 수 있다. 클라이언트는 클라이언트 간의 연결을 요청할 때 Sec-웹소켓-프로토콜 헤더를 사용하지 않을 수 있다. 서버는 클라이언트 간의 연결을 위한 요청에서 Sec-웹소켓-프로토콜 헤더를 무시할 수 있다. 서버는 Sec-웹소켓-프로토콜 헤더를 사용하는 프로토콜 확장을 위한 클라이언트 요청을 승인하지 않을 수 있다. 클라이언트가 Sec-웹소켓 확장 헤더를 사용하면 서버는 웹소켓 프로토콜 사양에서 정의된 방식으로 연결하지 못할 수 있다.

도 7에서 도시된 바와 같이, 클라이언트로 동작하는 HbbTV 어플리케이션이 "org.mychannel.myapp"의 app-endpoint와 /hbbtv/의 base-url-resource-name을 가지는 로컬 서비스 엔드 포인트와 연결을 시도할 수 있다. 컴패니언 장치와의 연결은 컴패니언 어플리케이션이 아직 동일한 app-endpoint를 사용하는 어플리케이션 간의 통신에 연결하지 못했기 때문에 대기 상태를 유지할 수 있다.

도 8은 일 실시 예에 따른 제2 클라이언트와 연결을 위한 새로운 연결 요청을 설명하는 도면이다.

도 8을 참조하면, HbbTV 어플리케이션(클라이언트)은 컴패니언 장치(200a)의 컴패니언 어플리케이션(클라이언트)과 연결되어 있다. 그리고, HbbTV 어플리케이션은 다른 클라이언트를 위한 다른 스트림 헤드를 생성할 수 있다.

서버는 동일한 app-endpoint를 가지는 동일한 본래 IP 어드레스로부터 하나 이상의 동시 대기 연결을 허락할 수 없다. 성공적으로 연결되거나 종료되기 전에 해당하는 IP 어드레스의 클라이언트가 동일한 app-endpoint를 사용하는 다른 연결 요청을 발행하면 서버는 403 금지 응답으로 반응할 수 있다.

클라이언트는 다른 리소스-네임 조합을 사용하는 동일한 서비스 엔드포인트를 통해 멀티플 동시 클라이언트 간의 연결을 설립하길 희망할 수 있다. 클라이언트는 존재하는 서비스 엔드포인트로의 연결 대기가 성공적으로 연결되거나 타임아웃되거나 연결 해제되기 전에 서비스 엔드포인트로 다른 연결의 요청을 시도할 수 없다. 이러한 클라이언트의 동작은 웹소켓 프로토콜 사양에 의해 정의될 수 있다.

도 8에 따르면, 만일 클라이언트가 하나 이상의 클라이언트와 통신하길 희망하면, 클라이언트는 존재하는 대기 연결이 페어링될 때가지 대기할 수 있다. 이때, 처리 가능한 클라이언트 간의 연결 최대 숫자에 다다를 때까지 추가 연결 요청을 서버로 발행될 수 있다. 즉, HbbTV 어플리케이션은 어플리케이션 간 통신의 설립을 허락하기 위한 새로운 대기 연결 요청을 생성할 수 있다.

한편, 클라이언트는 URI 경로에 IP 어드레스를 포함시킬 수도 있다.

도 9는 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 클라이언트의 설정을 설명하는 도면이다.

일 실시 예로서, 상술한 URI 경로(path)는 루트("/") 뒤에 HbbTV를 알리는 예약어("hbbtb")로 시작하고, 그 뒤에 기관/회사 구분자(org-id)와 어플리케이션 구분자(app-id)로 구성될 수 있다. 어플리케이션 간의 통신을 수행하고자 하는 어플리케이션이 타겟 어플리케이션을 지정하기 위해 URI의 경로에 타겟 어플리케이션이 구동중인 장치의 IP 어드레스를 추가할 수 있다. 웹소켓 서버는 웹소켓 API 콜의 URI 경로가 같은 어플리케이션 중 서로 통신하고자 하는 IP에 따라 연결시켜 줄 수 있다.

신택스) GET "/hbbtv/" target IP "/" org-id "." app-id

실시예) GET /hbbtv/1.1.1.1/org.mychannel.myapp

일 실시 예로서, TV 어플리케이션 A가 IP 1.1.1.1에서 구동 중이고, 컴패니언 어플리케이션 B가 IP 1.1.1.2(제1 사용자 단말기), 컴패니언 어플리케이션 C가 IP 1.1.1.3(제2 사용자 단말기)에서 구동 중일 수 있다. 이때, TV 어플리케이션 A가 컴패니언 어플리케이션 C와 서로 통신하려고 할 수 있다. TV 어플리케이션 A는 WebSocket 요청에 포함되는 URI의 경로에 컴패니언 어플리케이션 C가 구동 중인 IP(1.1.1.3)를 포함시킬 수 있다. 그리고, 컴패니언 어플리케이션 C는 웹소켓 요청에 포함되는 URI의 경로에 TV 어플리케이션 A의 IP(1.1.1.1)을 포함시킬 수 있다.

도 9에 따르면, URI 경로는 hbbtv/192.0.2.7/org.mychannel.myapp HTTP/1/1과 같을 수 있다. 여기서 192.0.2.7은 타겟 어플리케이션의 IP 어드레스일 수 있다. 192.0.2.110은 자신의 IP 어드레스일 수 있다. 그리고, org.mychannel.myapp는 어플리케이션 ID일 수 있다.

도 10은 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 및 제2 클라이언트의 설정을 설명하는 도면이다.

웹소켓 서버는 각각의 클라이언트로부터 도 9에서 설명한 URI 요청을 수신할 수 있다. 도 10을 참조하면, 192.0.2.110의 IP 어드레스를 가지는 제1 클라이언트와 192.0.2.7의 IP 어드레스를 가지는 제2 클라이언트가 있다. 제1 클라이언트가 제2 클라이언트로 연결을 요청하는 경우, 출발지(From Host)는 192.0.2.110이고, 도착지(To Host)는 192.0.2.7이 된다. 그리고, 어플리케이션 ID는 org.mychannel.myapp일 수 있다. 제2 클라이언트가 제1 클라이언트로 연결을 요청하는 경우, 출발지(From Host)는 192.0.2.7이고, 도착지(To Host)는 192.0.2.110이 된다. 그리고, 어플리케이션 ID는 org.mychannel.myapp일 수 있다. 즉, 제1 클라이언트와 제2 클라이언트의 출발지와 목적지 주소는 서로 반대될 수 있다. 그러나, 어플리케이션 ID는 동일하다. 웹소켓 서버는 매칭되는 클라이언트를 서로 연결시켜 줄 수 있다.

또한, 호스트 IP 어드레스를 포함하는 URI 경로가 사용될 수도 있다.

예를 들어, URI 경로는 Syntax) GET "/"hbbtv"/" host_address"/"org-id "." app-id,

실시예) GET /hbbtv/192.0.2.7/org.mychannel.myapp 와 같이 사용될 수 있다.

도 11은 IP 어드레스를 포함하는 경우 복수의 제2 클라이언트에 연결하는 일 실시 예를 설명하는 도면이다.

도 11을 참조하면, HbbTV는 일정한 IP 어드레스를 가지고, org.mychannel.myapp의 어플리케이션 ID를 포함하고 있다. 제1 컴패니언 어플리케이션 IP 어드레스는 192.0.2.7이고, 제2 컴패니언 어플리케이션 IP 어드레스는 192.0.2.1이다. 제1 및 제2 컴패니언 어플리케이션의 어플리케이션 ID는 org.mychannel.myapp이다. 도 10에서 설명한 바와 같이, 웹소켓 서버는 매칭되는 클라이언트를 서로 연결시켜 줄 수 있다. 따라서, 각 클라이언트들의 요청에 대응하여 웹소켓 서버는 매칭되는 클라이언트들을 서로 연결시켜 줄 수 있다.

이와 같이, URI 경로에 IP 어드레스를 사용하는 경우, 양 클라이언트는 연결 대상을 지정하기 때문에 보안성이 향상되고, 클라이언트 간 연결이 가능하며, 별도의 노력없이 모든 정보의 매칭이 가능하다는 장점이 있다. 한편, URI 경로에 IP 어드레스를 사용하는 경우에도 각 클라이언트는 동일한 포트를 사용할 수 있고, 서로 다른 포트를 사용할 수도 있다.

도 12는 일 실시 예에 따른 전자 장치의 제어 방법의 흐름도이다.

도 12에 따르면, 전자 장치는 컴패니언 장치와 연결할 수 있다(S1210). 전자 장치는 네트워크 프로세서와 어플리케이션 프로세서를 포함할 수 있다. 전자 장치는 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청할 수 있다. 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 연결 요청한 어플리케이션 프로세서와 컴패니언 장치를 연결할 수 있다.

상술한 바와 같이, 어플리케이션 프로세서는 어플리케이션 모듈, 어플리케이션 브라우저일 수 있다. 또는, HbbTV 어플리케이션일 수 있다. 네트워크 프로세서는 네트워크 모듈로 구현될 수 있다. 또는, 네트워크 프로세서는 웹소켓 서버(WebSocket Server)일 수 있다. 네트워크 프로세서가 웹소켓 서버로 구현되는 경우, 어플리케이션 프로세서와 컴패니언 장치는 각각 하나의 클라이언트라고 볼 수 있다. 또는, 제1 클라이언트와 제2 클라이언트를 각각 피어(peer)라고 부를 수도 있다.

어플리케이션 프로세서는 네트워크 프로세서에서 동작하는 전자 장치 정보 또는 컴패니언 장치 정보를 나타내는 호스트 요청 헤더 정보를 네트워크 프로세서로 전송할 수 있다. 그리고, 네트워크 프로세서는 어플리케이션 프로세서의 연결 요청이 있을 때, 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시킬 수 있다. 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 컴패니언 장치의 스트림 헤드를 생성하여 스트림 헤드 그룹으로부터 매칭되는 어플리케이션 프로세서의 스트림 헤드와 연결할 수 있다. 이때, 네트워크 프로세서는 매칭된 어플리케이션 프로세서의 스트림 헤드 또는 컴패니언 장치의 스트림 헤드를 스트림 헤드 그룹으로부터 제거할 수 있다. 한편, 어플리케이션 프로세서는 연결하려는 컴패니언 장치의 IP 어드레스를 전송할 수 있으며, 각각의 어플리케이션들은 동일한 포트를 이용할 수 있다.

전자 장치는 컴패니언 장치와 데이터를 송수신할 수 있다(S1220). 이와 같은 과정을 통해, 전자 장치는 컴패니언 장치와 연결하여 통신을 수행할 수 있다.

본 명세서에 따른 전자 장치 및 제어 방법은 상술한 실시 예들의 구성과 방법으로 한정되어 적용되는 것이 아니라, 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 다양한 변형이 이루어질 수 있다.

한편, 본 명세서의 전자 장치의 제어 방법은 전자 장치에서 구비된 프로세서가 읽을 수 있는 기록 매체에 소프트웨어로서 구현되는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

또한, 이상에서는 본 명세서의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 명세서의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.

발명의 실시를 위한 형태

-

전자 장치에서 사용 가능하고 반복 가능성이 있는 산업상 이용가능성이 있다.

Claims

어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부;
상기 컴패니언 장치와 데이터를 송수신하는 통신부;를 포함하며,
상기 어플리케이션 프로세서는,
상기 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고,
상기 네트워크 프로세서는,
상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결하는, 전자 장치.
제1항에 있어서,
상기 네트워크 프로세서는 웹소켓 서버인 것을 특징으로 하는 전자 장치.
제1항에 있어서,
상기 어플리케이션 프로세서는,
상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 네트워크 프로세서로 전송하는 것을 특징으로 하는 전자 장치.
제1항에 있어서,
상기 네트워크 프로세서는,
상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키고, 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 컴패니언 장치의 스트림 헤드를 생성하고, 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 것을 특징으로 하는 전자 장치.
제4항에 있어서,
상기 네트워크 프로세서는,
매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 것을 특징으로 하는 전자 장치.
제1항에 있어서,
상기 어플리케이션 프로세서는,
연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 것을 특징으로 하는 전자 장치.
제1항에 있어서,
상기 네트워크 프로세서는,
상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결하는 것을 특징으로 하는 전자 장치.
전자 장치의 제어 방법에 있어서,
컴패니언 장치와 연결하는 단계; 및
상기 컴패니언 장치와 데이터를 송수신하는 단계;를 포함하며,
상기 연결하는 단계는,
상기 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결하는, 전자 장치의 제어 방법.
제8항에 있어서,
상기 네트워크 프로세서는 웹소켓 서버인 것을 특징으로 하는 전자 장치의 제어 방법.
제8항에 있어서,
상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 어플리케이션 프로세서가 상기 네트워크 프로세서로 전송하는 단계;를 더 포함하는 전자 장치의 제어 방법.
제8항에 있어서,
상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 네트워크 프로세서가 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키는 단계; 및
상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 네트워크 프로세서가 상기 컴패니언 장치의 스트림 헤드를 생성하여 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 단계;를 더 포함하는 전자 장치의 제어 방법.
제11항에 있어서,
상기 네트워크 프로세서가 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 단계;를 더 포함하는 전자 장치의 제어 방법.
제8항에 있어서,
상기 어플리케이션 프로세서가 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 단계;를 더 포함하는 것을 특징으로 하는 전자 장치의 제어 방법.
제8항에 있어서,
상기 연결하는 단계는,
상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결하는 것을 특징으로 하는 전자 장치의 제어 방법.