KR20010012553A

KR20010012553A - 서버와 클라이언트노드 사이의 접속을 관리하기 위한시스템 및 방법

Info

Publication number: KR20010012553A
Application number: KR1019997010508A
Authority: KR
Inventors: 제이. 피터슨브라들리; 에이. 블룸필드마크
Original assignee: 사이트릭스 시스템스, 인크.
Priority date: 1997-05-14
Filing date: 1998-05-14
Publication date: 2001-02-15
Also published as: IL132873A; CA2290433A1; EP0981884A2; WO1998052320A2; DE69837550T2; IL132874A0; EP1017202B1; HK1025700A1; EP1017202A3; EP1017202A2; KR100569469B1; CA2290433C; ES2252837T3; EP1011236A2; DE69832168T2; ES2284448T3; IL132875A0; JP2005339536A; GB9926972D0; KR20040004436A

Abstract

서버 클라이언트 시스템의 서버에 통신 제어를 제공하는 접속관리기는 클라이언트노드가 지정된 서버 포트와 기본적인 소통을 설정하도록 허용한 후 서버에서 실행하는 어플리케이션에 통신 포트 특성에 접속한다. 이 후에, 특정 통신 포트는 클라이언트노드에 의해 요구된 프로토콜 드라이버를 갖는 통신관리기에 의해 구체화된다. 어플리케이션은 HTML 페이지에서 디스플레이된다. 일 실시예에서, 동일 데이타는 서버노드에서 실행하는 어플리케이션으로부터 실질적으로 동시에 적어도 두개의 클라이언트노드로 전송된다. 클라이언트-서버 시스템 내 서버노드는 관련된 클라이언트노드를 위하여 해석언어로 기록된 어플리케이션을 다운로드시키고 실행시킬 수 있다.

Description

서버와 클라이언트노드 사이의 접속을 관리하기 위한 시스템 및 방법{System and method for managing the connection between a server and a client node}

클라이언트 서버 컴퓨터 네트워크는 전형적으로 클라이언트 및 서버가 미리 설정된 몇 세트의 규약에 따라 통신을 설정할 것을 요청한다. 이들 규약들은 통신 프로토콜이라 한다. 이러한 프로토콜은 모든 클라이언트노드가 서버노드로서 동일 통신 프로토콜을 사용하도록 미리 정의될 수 있다. 대안으로, 서버는 각각의 클라이언트에 의해 사용된 통신 프로토콜의 기록을 유지할 수 있으며 클라이언트가 서버상의 어플리케이션과 통신하기 위해 리퀘스트(request)를 보냈을 때 클라이언트와 통신하기 위해 그 프로토콜을 사용한다.

이러한 통신방법과 관련된 문제는 프로토콜이 요청된 모든 기능을 필요로 하지 않는 어플리케이션을 위해 너무 엄격히 규정되었거나, 클라이언트 프로토콜이 서버와 통신할 수 있는 클라이언트보다 먼저 서버에 알려져야만 한다는 것이다. 본 발명은 미리 규정된 프로토콜의 완고성과 서버의 파트에 예비접속 보고의 필요성을 배제하려는 것이다.

섀도우잉(한 클라이언트노드를 위해 정해진 데이터를 실제로 동시에 제2클라이언트노드로 전송하는 것) 및 브로드캐스팅(동일 데이터를 하나 이상의 클라이언트노드에 실제로 동시에 전송하는 것)은 일반적으로 서버노드상의 특정화된 전송 어플리케이션과 클라이언트노드 각각의 특정화된 수신 어플리케이션을 사용하여 수행되었다. 쉐도잉은 데이터 트래픽을 모니터링하는데 유용하며 데이터 보존을 위해 전송되는 정보의 잉여 복사본의 생성과 시스템 보호 목적에 유용하다. 브로드캐스팅은 동일 정보가 "실시간"(REAL-TIME)일 때 및 정보가 그 자체에 시작과 종료를 가지지 않을 때 동일 정보를 많은 사용자에게 제공하는 데 유용하다. 예를 들어, 주가 시세 프로그램은 주어진 거래에 따라 다양한 주식의 현재가를 단순히 전송하며 그 리스트는 주식 리스트가 소멸되었을 때 최종가로 된다. 따라서, 그것은 어디에서 그 리스트가 시작되는 지를 시세 프로그램에 지정하지 않은 사용자와 관련이 없다.

일반적으로, 이러한 프로그램은 브로드캐스트 프로그램을 염두에 두고 기록되었으며 전송된 데이터를 수신하기 위해 특정화된 수신프로그램을 필요로 한다. 어플리케이션이 브로드캐스트 프로그램으로 기록되지 않았다면, 그러한 어플리케이션에 의해 전송된 데이터는 일반적으로 다수의 클라이언트노드에 동시전송되지 않는다.

본 발명은 브로드캐스트 기능을 위해 기록되지 않은 프로그램이 네트워크상의 브로드캐스트 데이터로 사용될 수 있도록 함으로써 이문제를 극복하려 한다.

하나의 특정화된 클라이언트 서버 네트워크는 지난 수년 동안 폭발적 성장을 보여 온 "인터넷"으로 일반적으로 알려진 컴퓨터의 세계적인 네트워크이다. 이러한 많은 성장은 월드 와이드 웹(WWW)의 대중성의 증가에 의해 이루어 졌다. WWW는 하이퍼 텍스트 마컵 언어(Hyper Text Markup Language; HTML)를 사용하여 기록된 파일의 모음이며, 일반적으로 웹페이지로 불려진다. HTML 파일은 웹 브라우저로 알려진 특정 어플리케이션을 이용하여 억세스되고 디스플레이될 수 있는데, 사용자가 간단한 그래픽 사용자 인터페이스(Graphical User Interface; GUI)를 사용하여 HTML 파일을 억세스할 수 있도록 한다.

HTML 파일을 호스팅하는 서버는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol; HTTP)을 이용하여 통신할 수 있다. HTTP는 HTML 페이지 설명 언어를 사용하는 파일(텍스트, 그래픽, 이미지, 비디오등과 같은 여러 형태가 될 수 있음)로 사용자 억세스를 제공하는 어플리케이션 프로토콜이다. HTML은 기본 문서 형식을 제공하며 개발자가 다른 서버 및 파일에 통신 "링크"를 지정하게 한다. HTML 컴플라이언트 클라이언트 브라우저(HTML_compliant client browser)는 유니폼 리소스 로케이터(Uniform Resource Locator) 또는 "URL"을 경유한 링크의 명세서를 포함한다. 이러한 명세서에 따라, 클라이언트는 링크에서 확인된 서버로 TCP/IP 리퀘스트를 작성하고 그 응신으로 "웹 페이지"를 수신한다. 또한, 조직(Organizations)은 WWW로부터가 아닌 그 조직 내로부터 억세스 가능한 HTML 파일을 제공할 수 있다. 이들 내부 네트워크 및 HTML 파일의 모음은 일반적으로 "인트라넷(Intranet)"으로 불려 진다.

HTML를 사용하여 기록된 파일은 "태그(Tags)"를 포함하는데, 그것은 특정 액션이 취해져야만 할 때 그 파일을 디스플레이하는 브라우저에 지시한다. 예를 들어, 태그는 브라우저에 (1) 그래픽 파일이 문서의 특정 포인트에 디스플레이되어야만 한다는 것; (2) 어떤 텍스트가 중심에 있어야만 한다거나, 볼드처리되어야만 한다거나 또는 달리 포맷되어야 한다는 것; (3) 문서의 배경이 음영처리되거나 특별한 패턴을 가져야만 한다는 것; 또는 (4) 다른 HTML이 현재 디스플레이되는 HTML 대신에 로드되어야만 한다는 것을 지시할 수 있다.

월드 와이드 웹 및 다른 HTML 어플리케이션의 대중성은 광범위한 산업계를 대표하는 회사의 넓은 영역에서 마케팅과 판매 노력에 매력적이다. 다른 회사와의 차별이 점점 어려워지므로 많은 회사는 HTML의 고유의 정정 성질을 극복하기 위해 애써 왔다. 또한, 정보를 할당하는 방법으로 HTML파일을 이용하는 조직은 인트라넷이 보다 올바른 정보로의 억세스에 다양한 사용자를 제공하기 위한 유용한 방법이란 것을 인식하게 되었다.

그러나, HTML 파일들의 주요 단점은 그들이 본질적으로 정적이란 것이다. 즉, HTML은 "디스플레이 전용(Only)" 언어 일뿐이며, 그것은 HTML 페이지 내에서 어플리케이션 실행을 쉽게 허용하지 않는다. WWW의 대중성과 편재를 지렛대 작용으로 이용하려는 회사들은 HTML 파일 내에 어플리케이션을 내장하는 방법을 점진적으로 찾고 있다.

액티브엑스 오브젝트(ActiveX object)는 실행 어플리케이션을 디스플레이하기 위한 능력을 가진 HTML 파일을 제공하려는 한 시도이다. 액티브엑스 오브젝트는 액티브엑스 인터페이스를 가진 브라우저로 사용될 수 있는 데이터 오브젝트이다. 이러한 오브젝트의 분명한 단점은 사용자 브라우저가 액티브엑스 인터페이스를 가지고 있지 않다면 그것은 실행 어플리케이션을 디스플레이 할 수 없다는 것이다. 모든 HTML 페이지의 주요 목적은 가능한 많은 사용자에 의해 보여지도록 하는 것이므로 이것은 엑티브엑스 오브젝트의 유용성을 제한한다.

또한 자바(JAVA)라 불리는 프로그래밍 언어가 실행 가능한 코드를 HTML 파일에 추가되도록 하는 방법으로 제안되었다. 자바는 언어이므로 그것은 특정한 브라우저 인터페이스를 필요로하지 않으며 잠재적으로 더 넓은 대중을 가진다. 그러나, 보통 애플릿(applet)이라 불리는 자바 프로그램은 실행전에 클라이언트로 다운로드된다. 이것은 클라이언트가 애플릿을 다운로드하기 위한 충분한 메모리가 부족하다는 문제가 있으며, 크라이언트가 충분한 메모리를 가지고 있을지라도 클라이언트가 애플릿을 다운로드하기 위해 기다릴 필요가 있다. 더욱이, 자바는 프로그래밍 언어 그자체이므로 실행 어플리케이션은 그들이 웹 페이지에 내장될 수 있기 전에 자바 언어로 재기록되어야만 한다.

본 발명은 분산형 클라이언트-서버 환경에서의 어플리케이션 실행에 관한 것 으로, 특히 클라이언트-서버 환경에서 해석언어로 기록된 어플리케이션의 원격 실행에 관한 것이다.

본 발명은 첨부된 청구범위에 한정된다. 상술된 본 발명의 장점들 뿐만 아니라 다른 특징들은 첨부된 도면과 관련하여 취해진 하기 설명을 참조함으로써 보다 쉽게 이해될 수 있다.

도 1은 본 발명을 채용하는 통신 시스템의 실시예의 개략적 다이어그램이다.

도 2는 클라이언트와 서버 사이의 통신 동안 발생하는 도 1의 서버의 다양한 구성요소들 사이의 접속을 나타내는 본 발명 실시예의 블록 다이어그램이다.

도 3은 다중 클라이언트노드 접속을 유지하고 관리하는 본 발명 실시예의 블록 다이어그램이다.

도 4는 HTML 페이지에서 어플리케이션를 내장하기 위한 시스템 실시예의 블록 다이어그램이다.

도 5는 클라이언트노드의 다이어그램 도면이다.

도 6은 어플리케이션로부터 하나 이상의 클라이언트까지 동일 데이타를 전송하는 다중장치의 사용을 나타내는 본 발명 실시예의 블록 다이어그램이다.

도 7은 동시전송기능이 팬아웃에 의해 증가되는 본 발명 실시예의 블록 다이어그램이다.

일특징에 있어서, 본 발명은 클라이언트노드와 서버노드상에서 실행되는 어플리케이션 간의 통신을 처리하는 통신 시스템 및 방법에 관한 것이다.

본 기술사상의 일실시예에 있어서, 방법은 클라이언트노드와 서버상에 설치된 일반 통신 포트간의 접속을 설정하는 단계를 포함한다. 방법은 엔드포인트(endpoint) 데이터 구조를 생성하는 단계, 크라이언트 스페이스를 엔드포인트 구조와 결합시키는 단계 및 어플리케이션과 결합된 특정 통신 포트용 프로토콜 스택(stack)을 생성하는 단계를 더 포함한다. 접속관리기에 접속이 통지(notification)되고 그 접속은 일반 접속으로부터 특정 통신 포트의 프로토콜 스택에 전송된다.

본 기술사상의 다른 실시예에 있어서, 접속을 설정하는 단계는 마스터 네트워크 정보노드에 의해 클라이언트노드로부터 어플리케이션 리퀘스트를 수신하는 단계; 마스터 네트워크 정보노드에 의해 리퀘스트된 어플리케이션을 갖는 서버의 서버 어드레스를 클라이언트노드에 제공하는 단계; 클라이언트노드로부터의 서버 리퀘스트에 의해 제공된 어드레스에 따른 일반 통신 포트로의 접속을 수신하는 단계; 및 클라이언트노드와 일반 통신 포트간의 접속을 설정하는 단계를 포함한다.

본 기술사상의 다른 실시예에 있어서, 통신 시스템은 서버노드 및 클라이언트노드를 포함한다. 서버노드는 일반적인 통신 포트를 구비한다. 클라이언트노드는 클라이언트노드와 서버노드의 일반 통신 포트간의 접속을 설정하는 통신 장치를 구비한다. 서버노드는 또한 엔드포인트 데이터 구조를 포함하는 프로토콜 스택을 포함하며 메모리에 설치된 클라이언트 스페이스를 포함한다. 클라이언트 스페이스는 프로토콜 스택과 관련된다. 통신관리기 및 통지 장치는 서버노드 상에 설치된다. 통지 장치는 클라이언트노드와 일반 통신 포트간의 접속을 통신관리기에 통지하며 그 응답으로 통신관리기는 일반 통신 포트와 클라이언트노드간의 접속을 프로토콜 스택에 전송한다. 일실시예에 있어서 시스템은 다수의 프로토콜 스택의 각 프로토콜 스택과 통신하는 다중장치를 더 포함한다.

본 기술사상의 또 다른 실시예에 있어서, 본 발명은 내장된 클라이언트노드와 통신하기 위한 컴퓨터-판독가능 프로그램 수단을 갖는 처리 장치에 관한 것이다. 상기 장치는 접속을 예정된 포트를 경유해 클라이언트노드에 설정하기 위한 컴퓨터-판독가능 수단; 엔드포인트 데이터 구조를 생성하기 위한 컴퓨터-판독가능 수단; 메모리 스페이스를 엔드포인트 데이터 구조와 결합시키기 위한 컴퓨터-판독가능수단; 메모리 스페이스 및 상기 결합된 엔드포인트 구조와 결합된 프로토콜 스택을 생성하기 위한 컴퓨터 판독가능 수단; 예정된 포트와 클라이언트 간의 접속을 접속관리기가 통지하기 위한 컴퓨터-판독가능 수단; 및 예정된 포트와 클라이언트 간의 접속을 상기 결합된 프로토콜 스택에 전송하기 위한 컴퓨터-판독가능 수단을 포함한다.

다른 기술사상에 있어서, 본 발명은 특정 언어로 기록될 어플리케이션의 요청없이 그리고 특정된 인터페이스를 지원하기 위한 윈도우 사용자의 브라우저의 요청없이 디스플레이된 HTML 파일의 실행 어플리케이션을 디스플레이하는 방법에 관한 것이다. 어플리케이션은 다운로드 타임과 클라이언트측 메모리 제한을 완하시키기 위해 서버상에서 실행한다. 더욱이, 클라이언트는 어느 어플리케이션의 종료없이 HTML 문서간의 이동과 다중 페이지용 다중 어플리케이션의 실행을 요청할 수 있다.

본 기술사상의 다른 실시예에 있어서, HTML 페이지에서 실행 어플리케이션을 디스플레이하는 방법은 사용자가 어플리케이션 프로그램의 실행을 시작하기를 원하는 것을 알리는 사용자로부터 입력을 수신하므로써 시작한다. 어플리케이션이 실행될 윈도우 파라미터가 결정되고, HTML 페이지 내에서 어플리케이션 윈도우로의 통신 채널이 생성된다. 서버상에서 실행되는 어플리케이션의 출력은 통신 채널을 통해 어플리케이션 윈도우에서 디스플레이된다.

본 기술사상의 또다른 실시예에 있어서, HTML 페이지에서 실행 어플리케이션을 디스플레이하기 위한 장치는 파라미터 핸들러 및 네트워크 실행부를 포함한다. 파라미터 핸들러는 HTML 파일에 포함된 어플리케이션 실행 윈도우와 결합되는 파라미터를 수신한다. 파라미터 핸들러는 서버상의 어플리케이션의 실행을 시작케하는 파라미터 핸들러로부터 파라미터를 수신하며, 그 파라미터 핸들러로부터 네트워크 실행부에 의해 수신된 파라미터에 따라 어플리케이션 실행 윈도우에서 실행 어플리리케이션의 출력을 디스플레이 한다.

본 기술사상의 또다른 실시예에 있어서, 생산 물품은 내장된 HTML 페이지에서 실행 어플리케이션을 디스플레이하기 위한 컴퓨터-판독가능 코드수단을 구비한다. 이 생산 물품은 서버상의 어플리케이션의 실행이 시작되는 것을 알리는 클라이언트로부터의 입력을 처리하는 컴퓨터-판독가능 코드수단을 포함한다. 또한, 그 생산 물품은 실행 어플리케이션이 디스플레이될 윈도우의 파라미터를 결정하기 위한 컴퓨터-판독가능 코드수단을 포함한다. 또한, 결정된 파라미터를 사용하여 HTML 페이지로의 통신채널을 생성하기 위한 컴퓨터-판독가능 코드수단과 상기 통신 채널을 통해 어플리케이션 윈도우의 서버상에서 실행되는 어플리케이션의 출력을 디스플레이하기 위한 컴퓨터-판독가능 코드수단을 포함한다.

본 기술사상의 또다른 실시예에 있어서, HTML 페이지에 어플리케이션을 내장하기 위한 시스템은 서버, 네트워크 실행부, 파라미터 핸들러 및 HTML 파일을 포함한다. 상기 서버는 어플리케이션 프로그램을 저장하고 실행한다. 네트워크 실행부는 특정 어플리케이션의 실행이 시작되어야만 하는 것과 네트워크 실행부가 서버상의 어플리케이션으로부터 출력을 수신하는 것을 지시하는 서버로 명령을 전달한다. 파라미터 핸들러는 파라미터를 수신하여 그들을 네트워크 실행부에 전송한다. HTML 파일은 어플리케이션 윈도우를 포함한다. 어플리케이션 윈도우는 윈도우 파라미터를 파라미터 핸들러에 전달하며 네트워크 실행부로부터 어플리케이션 프로그램 출력을 수신한다.

본 발명의 또다른 기술사상은 동일 데이터를 하나 이상의 클라이언트노드로 실제적으로 동시에 전송하기 위한 시스템 및 방법에 관한 것이다. 일실시예에 있어서, 본 발명은 실제적으로 동시에 동일 데이터를 서버상에서 실행되는 어플리케이션으로부터 일반화된 수신 프로그램을 실행하는 적어도 2 이상의 클라이언트노드로 전송하기 위한 방법에 관한 것이다. 그 방법은 제1클라이언트노드와 제1클라이언트 프로토콜 스택간의 접속을 설정하는 단계; 서버상에서 실행되는 어플리케이션과 제1클라이언트 프로토콜 스택간의 접속을 설정하는 단계; 제1최소 통신 프로토콜 스택을 제1클라이언트 프로토콜과 결합하는 단계; 서버노드상에서 실행되는 어플리케이션과 제1최소 통신 프로토콜 스택간의 접속을 설정하는 단계; 제2클라이언트노드와 제2클라이언트 프로토콜 스택간의 접속을 설정하는 단계; 제2최소 통신 프로토콜 스택을 제2클라이언트 프로토콜 스택과 결합하는 단계; 제1최소 프로토콜 스택과 제2최소 프로토콜 스택간의 접속을 제공하는 단계; 제2최소 프로토콜 스택과 제2클라이언트 프로토콜 스택간의 접속을 제공하는 단계; 및 어플리케이션 프로그램으로부터의 데이터를 제1클라이언트 프로토콜 스택과 제1최소 프로토콜 스택으로 실제적으로 동시에 전송하는 단계를 포함한다.

본 발명의 기술사상에 있어서의 다른 실시예는 서버 및 2 또는 그 이상의 클라이언트노드를 포함하는 통신 시스템에 관한 것이다. 일실시예에 있어서 서버노드는 어플리케이션 프로그램; 어플리케이션과 전기통신하는 제1클라이언트 프로토콜 스택;어플리케이션 프로그램과 전기통신하는 제1최소 프로토콜 스택;제1프로토콜 스택과 전기통신하는 제2최소 프로토콜 스택; 및 제2최소 프로토콜 스택과 전기통신하는 제2클라이언트 프로토콜 스택을 구비한다. 또한, 그 시스템은 제1클라이언트 프로토콜 스택과 전기통신하는 제1클라이언트노드와 제2클라이언트 프로토콜 스택과 전기통신하는 제2클라이언트노드를 포함한다. 어플리케이션으로부터의 데이터는 클라이언트 프로토콜 스택과 제1최소 프로토콜 스택으로 실제적으로 동시에 전송된다.

또다른 기술사상에 있어서, 본 발명은 클라이언트 서버 환경에서 해석언어를 원격으로 실행하기 위한 방법에 관한 것이다. 클라이언트가 접속된 서버는 자바 애플릿과 같은 해석언어로 기록된 어플리케이션을 다운로드하고 실행한다. 서버는 클리이언트로부터 입력을 수용하고 스크린 데이터를 클라이언트에 제공한다. 이것은 어플리케이션을 수용 및 실행하는 메모리 자원과 연산을 소모하기 위한 클라이언트 요청없이 통상적인 방법으로 어플리케이션을 수행하는 것 처럼 클라이언트에게 나타나게 한다. 또한, 서버는 클라이언트보다 빨리 어플리케이션을 다운로드 받을 수 있다. 서버는 또한 클라이언트로부터 입력을 수용하여 클라이언트노드가 입력을 제어할 수 있게 하며 다운로드된 어플리케이션에 제공할 수 있게 한다.

본 기술사상의 일실시예에 있어서, 본 발명은 클라이언트에 의해 만들어진 요청에 따라 서버노드로 어플리케이션을 다운로딩함으로써 시작하는 해석언어로 기록된 어플리케이션을 원격으로 실행하기 위한 방법에 관한 것이다. 접속은 클라이언트노드와 서버상에 위치된 예정된 통신포트간에 설정되며, 서버는 엔드포인트 데이터 구조를 생성하여 서버에 의해 지배되는 클라이언트 스페이스를 엔드포인트 데이터 구조와 결합시킨다. 서버는 클라이언트 스페이스 및 결합된 엔드포인트 데이터 구조가 결합된 프로토콜 스택을 생성하고, 접속관리기가 그 접속을 통지케하며, 예정된 통신 포트와 클라이언트노드 간의 접속을 결합된 프로토콜 스택으로 전송케한다.

본 기술사상의 또다른 실시예에 있어서, 본 발명은 해석언어로 기록된 어플리리케이션을 원격으로 실행하기 위해 그 내부에 내장된 컴퓨터-판독가능 프로그램 수단을 구비한 처리장치에 관한 것이다. 상기 처리 장치는 클라이언트노드에 의해 만들어진 요청에 따라 어플리케이션을 서버로 다운로딩하기 위한 컴퓨터-판독가능 프로그램 수단; 클라이언트노드와 서버상에 위치된 예정된 통신 포트간의 접속을 설정하기 위한 컴퓨터-판독가능 프로그램 수단; 엔드포인트 데이터 구조를 생성하기 위한 컴퓨터-판독가능 프로그램 수단; 서버에 의해 지배되는 클라이언트 스페이스를 엔드포인트 데이터 구조와 결합시키기 위한 컴퓨터-판독가능 프로그램 수단; 클라이언트 스페이스 및 상기 결합된 엔드포인트 데이터 구조가 결합된 프로토콜 스택을 생성하기 위한 컴퓨터-판독가능 프로그램 수단; 접속관리기가 접속을 통지하기 위한 컴퓨터-판독가능 프로그램 수단; 및 예정된 통신 포트와 클라이언트노드간의 접속을 결합된 프로토콜 스택으로 전송하기 위한 컴퓨터-판독가능 프로그램 수단을 포함한다.

본 기술사상의 또다른 실시예에 있어서, 본 발명은 해석언어로 기록된 어플리케이션을 원격으로 실행하기 위한 시스템에 관한 것이다. 본 시스템은 예정된 통신 포트를 갖는 서버노드 및 클라이언트노드와 서버노드의 에정된 통신 포트 간의 접속을 설정하는 통신 장치를 갖는 클라이언트노드를 포함한다. 프로토콜 스택은 서버노드 상에 설치되며 프로토콜 스택은 엔드포인트 데이터 구조를 포함한다. 서버노드상의 메모리에 위치된 클라이언트 스페이스는 프로토콜 스택과 결합되며 해석언어로 기록된 어플리케이션을 위한 환경을 제공한다. 본 시스템은 서버노드상에 위치된 통신관리기 및 서버노드상에 위치된 통지 장치를 더 포함한다. 통지 장치는 접속관리기가 클라이언트노드와 예정된 통신 포트간의 접속을 통지케 하며 통신관리기가 예정된 통신 포트와 클라이언트노드간의 접속을 프로토콜 스택으로 전송케 한다.

도 1을 참조하면, 개략적으로, 전형적인 네트워크(20)는 적어도 하나의 클라이언트노드(24)와, 적어도 하나의 서버노드(34, 34')와, 통신 링크(44)에 의해 서로 접속된 마스터 네트워크 정보노드(40)를 포함한다. 도1에 예시된 실시예는 통신 링크(44)를 근거리 통신망 링 또는 LAN 링으로 나타냈지만, 다른 통신 접속형태(topology)가 사용될 수 있다. 설명의 목적을 위하여, 서버노드(34)는 클라이언트노드(24)에 의해 요구된 어플리케이션(30)를 갖는 것으로 고려된다. 또한, 설명의 목적을 위하여, 마스터 네트워크 정보노드(40)는 별개의 서버노드인 것으로 고려되지만, 실제적으로 마스터 네트워크 정보노드(40)는 어플리케이션실행 서버노드(34)이다. 제공된 LAN 상에서 다수 노드가 네트워크 정보노드(40)로 작용할 수 있지만, 어느 한 순간에 이러한 노드 중 하나가 시스템(20)용 마스터 네트워크 정보노드(40)를 지정하고 서버 정보에 필요한 클라이언트 요구가 이 노드에 지시된다는 것을 인식해야 한다.

마스터 네트워크 정보노드(40)는 어플리케이션실행 서버노드(34, 34')용 어드레스의 테이블을 보유한다. 부가적으로, 마스터 네트워크 정보노드(40)는 각 어플리케이션실행 서버노드(34, 34')로부터 작동 레벨을 나타내는 메시지를 수신한다. 어플리케이션실행 서버노드(34, 34')의 작동 레벨은 각 어플리케이션실행 서버노드(34)의 어드레스와 함께 테이블에 보유되고 로드 레벨링(load leveling)에 적합한 통신체계(44)에 의해 사용된다.

클라이언트(24)가 어플리케이션실행 서버노드(34) 상에서 실행된 어플리케이션를 갖기를 원할 때, 클라이언트노드(24)는 프로토콜에 의해 이미 규정된 일반적인 통신포트 또는 마스터 네트워크 정보노드(40) 상의 "공지된" 통신포트에 대한 리퀘스트를 송신한다. 일실시예에서, 통신은 데이타그램 서비스의 경로에 의해 발생한다. 마스터 네트워크 정보노드(40)에 대한 초기조회가 이루어지는 프로토콜의 형태는 마스터 네트워크 정보노드(40)에 의해 클라이언트노드(24)에 회송된 정보의 프로토콜을 결정한다. 따라서, TCP/IP 데이타그램을 사용하는 리퀘스트가 이루어지면, 마스터 네트워크 정보노드(40)는 서버(34)의 TCP/IP 어드레스를 클라이언트노드(24)로 회송하고 클라이언트노드(24)는 그 프로토콜을 사용하는 서버노드(34)와 실질적으로 접촉할 것이다. 다른 실시예에서, 클라이언트(24)에 의해 어플리케이션 어드레스를 리퀘스팅하는 데이타그램은 마스터 네트워크 정보노드(40)에 리퀘스트를 송신하도록 사용된 것과는 다른 프로토콜의 형태에 대한 리퀘스트를 포함한다. 예를 들어, 클라이언트(24)는 IPX 프로토콜을 사용하는 마스터 네트워크 통신노드(40)에 대한 리퀘스트를 제작하고 TCP/IP 프로토콜 어드레스로서 어플리케이션서버의 어드레스를 요구한다.

클라이언트노드(24)[실제적으로 클라이언트노드(24) 상의 클라이언트 프로세스(56)]가 서버노드(34, 34') 상의 어플리케이션와 통신하기를 요구할 때, 클라이언트노드(24)는 요구된 어플리케이션를 갖는 서버(34)의 위치를 판단하도록 네트워크 리퀘스트를 명령함으로써 시작한다. 이 리퀘스트는 네트워크 상의 어느곳에선가 내재하는 마스터 네트워크 정보노드(40)[네트워크 브라우저(40)로서 언급됨]에 의해 수신된다. 도 1에서, 네트워크 브라우저(40)는 어플리케이션를 갖는 서버와는 다른 서버(40) 상에 내재하므로 단순히 도시되어 있지만, 이것은 일반적으로 케이스가 아니다.

네트워크 마스터 정보노드(40)는 요구된 어플리케이션(30)를 갖는 서버노드(34)의 네트워크 어드레스를 클라이언트노드(24)로 복귀시킨다. 그리고, 클라이언트노드(24)는 특정 서버(34) 상에서 실행하는 어플리케이션에 접속하도록 네트워크 마스터 정보노드(40)로부터 수신된 정보를 사용한다. 상술된 바와 같이, 이러한 접속은 먼저 "공지된" 통신포트로 설정된 후 접속 관리의 제어하에서 특정 통신포트로 전송된다. 특정 통신포트는 서버노드(34) 상에서 실행하는 어플리케이션와 관련되어, 서버노드는 특정 통신포트를 통해 클라이언트노드(34)와 통신한다.

상세하게는, 도 2를 참조하면, 클라이언트노드(24) 상의 클라이언트 프로세스(56)는 요구된 어플리케이션(62)를 포함하는 서버노드(34)의 어드레스를 얻도록 네트워크 마스터 정보노드(40)에 대한 리퀘스트(54)를 형성한다. 네트워크 마스터 정보노드(40)는 서버 어플리케이션(62)를 포함하는 서버노드(34)의 어드레스를 포함하는 메시지(58)를 클라이언트노드(24)로 복귀시킨다. 일실시예에서, 접속의 순간에 사용된 프로토콜은 데이타그램 서비스이다.

클라이언트노드(24)는 서버(34)와 통신채널(68)을 설정하도록 복귀된 어드레스를 사용한다. 클라이언트(24)에 의해 사용된 포트수는 서버(34)가 클라이언트(24)와의 통신접속을 설정하는 포트로서 네트워크 프로토콜에 의해 정의된 서버(34)에서 "공지된 포트"에 대응한다. 공지된 포트(72)는 엔드포인트 데이타 구조(78)를 주로 포함하는 기본 프로토콜 스택(76)을 갖는다.

엔드포인트 데이타 구조(78)는 프로토콜 스택(76)을 가리키고 이에 의해서 클라이언트 접속은 유일 표현 또는 클라이언트(24)를 위한 "핸들"을 설정한다. 엔드포인트 데이타 구조(78)는 서버(34) 상에서 접속관리기(80)와 다양한 어플리케이션 사이에서 이동하고자 하는 클라이언트(24)와 서버(34) 사이의 접속을 허용한다. 일실시예에서, 엔드포인트 데이타 구조(78)는 클라이언트(24)에 대한 핸들을 포함할 뿐만 아니라 클라이언트 접속에 관계하는 다른 정보를 포함할 수 있다. 예시된 실시예에서, 어플리케이션 서버(34)는 특정 통신체계(예를 들어, LAN 또는 WAN) 상에서 활동을 조절하고 :TTY" 통신모드를 지지하도록 요구된 필요한 프로토콜 모듈만으로 이 최소 프로토콜 스택(76)을 초기화시킨다. "TTY" 통신모드는 트랜스포트층 이상의 프로토콜가정이 없는 단순한 ASCII 스트림이다. 즉, 전송된 데이타의 압축, 암호화, 신뢰성, 프레임 비우기(framing) 또는 제시(presentation)에 적합한 프로토콜층이 없다. 따라서, 서버(34) 상에서 실행하는 어플리케이션(62)를 탐색하는 클라이언트노드(24)는 TTY 통신모드를 지지하는 데 요구되는 최소 프로토콜 세트로 공지된 통신포트(72)를 설정한다.

서버노드(34) 상에 실행하는 통신관리기(80)는 접속 리퀘스트(68)에 적합한 공지된 통신포트(72)에 "리스닝"(listening)한다. 접속 리퀘스트(68)가 클라이언트노드(24)로부터 수신되면, 접속관리기(80)는 이를 통지한다(84).

이 정보와 함께 접속관리기(80)는 신규의 최소 프로토콜 통신스택(104)를 생성하고, 실행환경(96)을 개시하고, 신규 최소 프로토콜 스택(104)을 실행환경(96)으로 설정(bind)한다. 일실시예에서, 서버(34)는 이미 시작하였지만, 통신포트와 관련되지 않은 다수의 실행환경(96)을 포함한다. 이 실시예에서, 실행환경의 예비접속 개시는 접속 리퀘스트가 클라이언트(24)로부터 수신되었을 때 각각의 실행환경(96)이 개시되는 경우보다 빠른 응답시간을 허용한다. 실행환경(96)이 개시될 때, 클라이언트(24)에 의해 요구된 서버 어플리케이션(62)도 개시된다. 다른 실시예에서, 클라이언트(24)가 어플리케이션를 특정하지 않으면, 드폴트 어플리케이션가 개시되거나 또는 단순히 어플리케이션가 없는 실행환경(96)이 개시된다.

따라서, 통신관리기(80)는 유일한 클라이언트 식별명 또는 핸들을 포함하는 클라이언트 접속을 공지된 포트(76)로부터 신규 최소 프로토콜 스택(104)으로 가동시킨다. 최소 프로토콜 스택을 사용하는 통신관리기(80)는 표시 서비스가 가능한 TTY 데이타 스트림을 전송한다. 따라서, 클라이언트 접속을 검출하기 위한 이 방법은 접속이 먼저 설정되는 포트와 무관하다. 클라이언트노드(24)가 지정된 시간(예를 들어, 5초) 내에 서비스 유효 메시지로 응답하지 않으면, "서비스 유효" 메시지의 재송신이 서버(34)에 의해 수행된다.

클라이언트(24)가 메시지를 수신하면, 클라이언트(24)는 "서비스 유효" 메시지가 검출된 것을 나타내는 TTY 스트링(string)을 전송한다. 클라이언트(24)는 서버(34)가 응답하는 것을 대기하고 응답이 지정된 시간(예를 들어, 5초) 내에 없으면 클라이언트(24)는 메시지를 재송신한다. 따라서, 접속관리기(80)는 클라이언트의 디폴트 통신 파라미터인지를 클라이언트(24)에게 조회한다(90). 이 조회(90)는 클라이언트(24)에게 다시 전달되고 클라이언트(24)가 무슨 프로토콜을 접속하여 사용하고자 하는 지에 관한 상세한 내용으로 응답해야 하는 메시지의 형태로 취해진다.

응답시, 클라이언트(24)는 일단의 프로토콜 패킷(92)을 전송하고, 각각의 패킷은 서버(34)로부터 요청되어지는 리퀘스트된 또는 옵션의 프로토콜 모듈을 상세하도록 사용된다. 일실시예에서, 일단의 패킷의 수는 요청된 각 프로토콜에 적합하게 전송된 하나의 패킷으로 변형될 수 있다. 다른 실시예에서, 전송되고자 하는 패킷의 수는 제1패킷의 헤더에 포함된다. 제3실시예에서, 전송되고자 하는 패킷의 잔류수는 각 패킷의 헤더에 포함되고 각 패킷이 연속하여 전송됨에 따라 감산된다. 따라서, 클라이언트(24)는 예를 들어 암호화 및 데이타 압축이 사용되는 것을 나타냄으로써 조회(90)에 응답할 수 있다. 이 경우에, 두개의 프로토콜 패킷은 클라이언트(24)로부터 서버(34)로 전송될 것이고, 일실시예에서, 제1패킷의 헤더는 패킷의 수를 2로 표시할 것이다.

일단 조회(90)에 대한 응답이 수신되면, 접속관리기(80)는 클라이언트노드(24)에 의해 요청된 프로토콜에 대응하는 프로토콜 드라이버(120, 120', 120")을 사용하는 프로토콜 스택을 형성한다. 일실시예에서, 통신관리기(80)는 요청된 클라이언트 프로토콜에 대응하는 각각의 요구된 프로토콜 드라이버(120, 120', 120")(예를 들어, 암호화가 클라이언트에게 요구되면 암호화 드라이버)를 프로토콜 스택 "콘테이너"에 배치시키고 이들을 서로 링크한다. 이 동적 프로세스는 서버(34)가 특정 클라이언트노드(24)용 이전 프로토콜 스택 설명을 구비할 것을 요구하지 않고 클라이언트노드(24)가 프로토콜 스택의 내용을 동적으로 설명하도록 한다. 이 방법을 사용하면, 각각의 클라이언트(24)가 관련된 통신 채널용 광범위하게 상이한 요구사항을 구비하여도, 다중 클라이언트(24)는 단일 서버에 의해 처리될 수 있다. 예시된 실시예에서, 각 클라이언트(24, 24', 24")는 개별적인 통신 프로토콜 스택(104, 104', 104")과 관련된다. 이러한 동적으로 확장가능한 프로토콜 스택들은 하기에 더욱 상세히 설명되고 1995년 10월 11일에 출원된 미국 특허출원 제08/540,891호는 본 명세서에 참조문헌으로 합체된다.

상술된 실시예에서, "콘테이너"(112)는 NT 장치 드라이버와 같은 사용자 레벨 또는 커널 레벨 장치 드라이버이다. 이 콘테이너는 클라이언트노드(24)의 프로토콜 요구사항에 대응하는 내적 프로토콜 모듈 또는 "드라이버"(일반적으로 120)에 적합한 보조 서포트를 제공한다. 이 보조 서포트는 예를 들어, 하나의 프로토콜 드라이버가 데이타를 다음 드라이버로 전송하는 데 협력하는 조력자 경로(helper routine)의 형태이다. 대안으로, 다른 실시예에서, 각 프로토콜 드라이버는 그 자체가 완전한 사용자-레벨 또는 커널-레벨이다.

이제, 도 3에 도시된 실시예를 참조하면, 통신관리기(60)는 두개의 주요 소프트웨어 모듈: ICASRV.EXE90 및 ICAAPI.DLL94을 포함한다. 예시된 실시예에서, ICASRV.EXE90은 클라이언트/서버 인터페이스의 서버측이다. ICASRV.EXE90은 모든 통신 상태를 관리하고. 일실시예에서, WINDOWS NT^TM서비스로서 내장된다. 접속관리기(60)의 제2부분은 ICAAPL.DLL94이다. ICAAPL.DLL94는 클라이언트와 접속을 설정하고, 사용되고자 하는 프로토콜을 설정하고, 프로토콜 스택의 완성을 ICASRV.EXE90에 통지한다. 일실시예에서, 제3모듈 CDMODEM.DLL96은 ICAAPL.DLL94'에 링크된다. CDMODEM.DLL96은 ICAAPI.DLL94'가 모뎀 장치와 소통하도록 사용하는 모듈이다.

상술된 접속 방법론은 웹브라우저 프로그램을 실행하는 클라이언트(24)용으로 사용될 수 있다. 이 설명의 목적을 위하여, 웹브라우저 프로그램을 실행하는 사용자는 "윈도우 사용자"(viewing user)로 언급될 것이다. 용어 "서버" 또는 "서버노드"는 실행될 수 있는 머신 호스팅 HTML 파일 또는 어플리케이션로 언급되도록 사용될 것이다. 예를 들어, 윈도우 사용자는 클라이언트노드에서 웹브라우저를 실행하고 HTTP 프로토콜을 경유하여 서버에게 파일 리퀘스트한다. 서버는 파일 데이타를 HTTP 프로토콜을 통해 클라이언트에게 전송함으로써 응답한다. 클라이언트가 전송된 데이타를 수신하면 웹브라우저가 실행되고 데이타를 HTML 페이지로서 윈도우 사용자에게 표시한다.

도 4를 참조하면, 서버(34')에 위치되고 본 발명의 실시예에 따라 제작된 HTML 파일(64)은 총칭 내장 윈도우태그(66)를 포함한다. 총칭 내장 윈도우태그(66)는 총칭 내장 윈도우(66')가 HTML 파일(64)에 의해 설명된 HTML 페이지(64') 내의 특정 위치에 배치되어야 하는 HTML 파일(64)을 표시하는 브라우저(60)를 지시하는 데이타 구조이다. 총칭 내장 윈도우태그(66)는 어플리케이션가 윈도우에서 표시될 수 있고 종종 출력 표시가 갱신되어야 하는 윈도우 높이, 윈도우 폭, 윈도우 경계 스타일, 윈도우 내 배경 색상 및 형태와 같은 추가 정보 또는 어플리케이션 출력의 디스플레이를 향상시키는 데 사용가능한 다른 추가정보를 포함할 수 있다.

HTML 파일에 내장될 수 있는 총칭 내장 윈도우태그는 하기와 같다.

ActiveX tag

〈object classid="clsid:238f6f83-b8b4-11cf-8771-00a024541ee3"

data="/ica/direct.ica"CODEBASE="/cab/wfica.cab"

width=436height=295〉

〈param name="start"value="Auto"〉

〈param name="Border"value="On"〉

〈/object〉

Netscape Plugin tag

〈embed src="http://www.citrix.com/ica/direct.ica"

pluginspage="http://www.citrix.com/plugin.html"

height=295 width=436 Start=Auto Border=On〉

〈embed〉

JAVA tag

〈applet code=JICA.class width=436 height=295〉

〈param name=Address value="128.4.1.64"〉

〈param name=InitialProgram value=Microsoft Word 7.0〉

〈param name=Start value=Auto〉

〈param name=Border value=On〉

〈/applet〉

상기 각 경우에서, 태그는 295 픽슬의 높이와 436 픽슬의 폭을 갖는 윈도우는 어플리케이션 출력을 수신하도록 모사되어야 한다는 것을 나타낸다. 각 태그는 또한 어플리케이션가 자동적으로 실행을 개시하여야 하고 어플리케이션 출력이 표시되는 윈도우가 경계선으로 모사되어야 한다는 것을 명시한다. 액티브X와 네츠케이프 플러진 태그는 "/ica." 디렉토리에 위치된 "direct.ica" 파일에 명시된 원격 어플리케이션 파라미터를 갖는다. JAVA 태그는 원격 어플리케이션 파라미터를 직접 명시한다. 상기 예에서, 어플리케이션를 호스팅하는 서버의 어드레스 뿐만 아니라 실행되고자 하는 어플리케이션의 네임(name)은 명시된다.

브라우저 어플리케이션(60)는 리퀘스트를 특정 Uniform Resource Locator(URL) 어드레스에 송신함으로써 HTML 파일(64)에 억세스한다. HTML 파일(64)을 호스팅하는 서버(34')는 HTML 파일(64) 데이타를 브라우저 어플리케이션(60)에 전송하여, 텍스트를 디스플레이하고 HTML 파일(64)에 포함되는 태그를 번역한다. 브라우저 어플리케이션(60)은 HTML 파일(64) 데이타를 HTML 페이지(64')로 디스플레이한다. 총칭 내장 윈도우 태그(66)가, 상술된 태그들 중 하나와 같이, HTML 파일(64) 내에 존재하면, 브라우저(60)는 표시된 HTML 페이지(64') 내에 블랭크 윈도우(66')를 모사한다.

요구된 어플리케이션(62')의 실행은 HTML 페이지(64')의 디스플레이때 즉시 시작할 수 있거나 또는 실행은 신호, 예를 들어 개시하여야 하는 어플리케이션(62')의 실행을 표시하는 특정 사용자 입력신호를 대기한다. 일단, 어플리케이션(62')의 실행이 시작되면, 브라우저 어플리케이션(60)는 어플리케이션 윈도우(66')와 관련된 파라미터 핸들러(40)를 증명한다. 파라미터 핸들러(40)는 브라우저 어플리케이션(60)의 챠일드(child) 프로세스, 브라우저 어플리케이션(60)의 동위(peer) 프로세스, 또는 브라우저 어플리케이션(60)와 관련된 동적으로 링크된 라이브러리("DLL")로서 즉시 야기될 수 있다.

브라우저 어플리케이션(60)는 총칭 내장 윈도우 태그(66)에 의해 제공된 어플리케이션 윈도우(66')와 관련된 특정 파라미터를 파라미터 핸들러(40)로 즉시 전달한다. 부가적으로, 브라우저 어플리케이션(60)는 어플리케이션 윈도우(66')용 핸들러를 파라미터 핸들러(40)로 즉시 전달할 수 있거나 또는 파라미터 핸들러(40)는 브라우저 어플리케이션(60)가 어플리케이션 윈도우(66')용 핸들러를 회수하도록 조회할 수 있다. 파라미터 핸들러(40)는 또한 네트워크 실행(50)을 즉시 야기한다. 네트워크 실행(50)은 파라미터 핸들러(40)의 챠일드 프로세스 또는 파라미터 핸들러(40)의 동위 프로세스로서 즉시 야기될 수 있다.

파라미터 핸들러(40)는 특정 어플리케이션 윈도우 파라미터(66')를 네트워크 실행부(50)로 즉시 진행한다. 파라미터 핸들러(40)에 의해 즉시 명시되지 않은 파라미터 또는 총칭 내장 윈도우 태그(66)는 디폴트값으로 설정될 수 있다. 네트워크 실행부(50)는 하드-코드된 소정의 파라미터 디폴트를 가질 수 있거나 또는 네트워크 실행부(50)는 파라미터 디폴트를 포함하는 파일에 억세스할 수 있다.

네트워크 실행부(50)는 서버(60)와 통신 채널을 설정하고 상술된 접속방법을 사용하는 서버(34")에 의해 요구된 어플리케이션(62')의 실행을 호출한다. 상기 설명에서 클라이언트로서 작용하는 네트워크 실행부(50)는 파라미터 핸들러(40)로부터 증명을 수신하였된 파라미터를 필요한 디폴트값과 함께 서버로 전달한다. 파라미터가 서버로 전달되지 않으면, 서버는 디폴트값을 갖지 않은 필요한 파라미터, 예를 들어 "user id"이면 파라미터를 리퀘스트할 수 있거나 또는 파라미터용 디폴트값, 예를 들어 실행 우선순위를 제공할 수 있다. 서버(34")는 요구된 어플리케이션 프로그램(62')의 실행을 개시하고 출력을 네트워크 실행부(50)로 향하게 한다. 네트워크 실행부(50)는 어플리케이션 프로그램(62')으로부터 데이타를 수신하고 출력 데이타를 그 어플리케이션 출력 윈도우(66")에 표시한다. 어플리케이션 출력 윈도우(66")는 브라우저 어플리케이션(60)에 의해 모사된 어플리케이션 윈도우(66')의 상부 상에 모사되므로, 어플리케이션 출력 데이타는 HTML 페이지(66')에 표시된다. 상술된 바와 같이, 네트워크 실행부(50)에 의해 모사된 어플리케이션 출력 데이타는 브라우저 어플리케이션(60)에 의해 모사된 어플리케이션 윈도우(66')의 챠일드이다. 이것은 HTML 페이지(64')가 스크롤될 때 어플리케이션 출력 윈도우(66")가 스크롤하도록 허용한다.

어플리케이션 출력 윈도우(66")는 또한 윈도우 사용자로부터 입력을 수신한다. 생(raw) 입력데이타, 예를 들어 마우스 클릭은 네트워크 실행부(50)에 의해 어플리케이션 출력 윈도우(66")로 수신된다. 네트워크 실행부(50)는 생 입력데이타를 서버(34") 상에서 실행하는 어플리케이션(62')으로 진행시킨다. 이 방식에서, 윈도우 사용자는 HTML 페이지(64')를 경유하여 어플리케이션(62')과 상호작용할 수 있다.

도 5를 참조하면, 윈도우 사용자는 사용자 컴퓨터(14)의 스크린(18) 상에 어플리케이션 윈도우(66')를 갖는 HTML 페이지(64')를 디스플레이하도록 소위 " 브라우저" 프로그램을 사용한다. 윈도우 사용자는 어플리케이션 프로그램(62')의 실행을 호출할 수 있다. 전형적으로, 이것은 "포인트-앤드-클릭" 인터페이스를 사용하는 사용자, 즉 윈도우 사용자가 윈도우 사용자 컴퓨터(14)의 스크린(18) 상에 디스플레이되는 커서(12)를 조작하도록 마우스(16)를 사용함으로써 수행된다. 일단, 커서(16)가 HTML 페이지(64')의 특정 부분 위에 있으면, 윈도우 사용자는 마우스(16) 상의 버튼(15)을 "클릭"함으로써 신호를 보낼 수 있다. 대안으로, 윈도우 사용자는 또한, "리턴" 키와 같은 관련된 키보드(17) 상의 키를 누름으로써 신호를 보낼 수 있다. 다른 실시예에서, 윈도우 사용자는 마우스(16)를 전혀 사용하지 않지만, 대신에 터치패드, 트랙볼, 감압 태블렛 및 펜 또는 커서(12)를 조작하기 위한 다른 입력기구를 사용할 수 있다.

다른 실시예에서, 어플리케이션 윈도우(66') 또는 HTML 페이지(64')의 다른 부분은 "핫 존"으로 정의될 수 있다. 윈도우 사용자가 커서(12)를 "핫 존"으로 이동할 때, 서버(34") 상의 어플리케이션(62')의 실행이 개시된다.

일단 윈도우 사용자가 어플리케이션(62')의 실행이 시작되어야 한다는 것을 나타내면, 브라우저 어플리케이션(60)은 파라미터 핸들러(40)를 증명하고 총칭 내장 윈도우 태그(66)에 의해 어플리케이션 윈도우(66')와 관련된 증명 파라미터를 통과시킨다. 파라미터 핸들러(40)는 네트워크 실행부(50)를 야기시키고 어플리케이션 윈도우(66')의 파라미터로 보낸다. 네트워크 실행부(50)는 어플리케이션(62)이 호출되려는 것과 어플리케이션(62')이 서버(34") 상에 존재하는 것을 결정한다. 일반적으로, 이 정보는 브라우저 어플리케이션(60)으로부터 총칭 내장 윈도우 태그(66) 형태로 얻어지는 파라미터 핸들러(40)에 의해 즉시 통과하지만, 네트워크 실행부(50)는 가능하다면 요구되는 어플리케이션(62')을 서버하고 호스트하는 것을 결정하기 위하여 마스터 네트워크 정보노드(40) 또는 다른 다양한 서버를 조회할 필요가 있다. 그리고, 네트워크 실행부(50)는, 상술된 바와 같이, 어플리케이션의 실행을 실시하고 어플리케이션 윈도우(66')에서 어플리케이션 프로그램(62')의 출력을 디스플레이한다.

네트워크 실행부(50)는 어플리케이션(62')의 실행이, 예를 들어 어플리케이션 윈도우(66')를 닫음으로써 정지되어지는 것을 윈도우 사용자가 지시하거나 또는 다른 HTML 페이지가 디스플레이되어야 하는 것을 지시하는 태크 상에 윈도우 사용자가 클릭할 때까지 어플리케이션 출력 윈도우(66")에 어플리케이션 출력을 직접 디스플레이한다. 이것이 발생할 때, 어플리케이션(62')의 실행이 끝날 수 있다. 그러나, 접속을 "캐시"(cache)하는 것이 바람직하다. 효과적으로, 제1파라미터 핸들러(40)는, 예를 들어, 즉시 종료되지 않는다. 그러나, 어플리케이션(62')은, 제1파라미터 핸들러(40)가 더 이상 "집중"(focus)되지 않기때문에, 낮은 우선순위 레벨, 즉 "백그라운드" 모드에서 실행을 계속한다.

일반적으로, 파라미터 핸들러(40) 소스 코드에 실례들을 레지스터하기 위한 전체적으로 억세스가능한 데이타 구조를 제공함으로써 접속 캐싱을 수행하는 것이 바람직하다. 예를 들어, 파라미터 핸들러(40)에는 전체적으로 억세스가능한 링크된 리스트 데이타 구조, 데이타 어레이, 데이타 테이블 또는 다른 데이타 구조가 제공될 수 있다. 데이타 구조는 전체적으로 이용가능하기 때문에, 파라미터 핸들러(40)의 각 실례는 데이타 구조를 판독하고 기록할 수 있다. 이것은 파라미터 핸들러(40)의 각 실례가 "레지스터"하도록 하여 모든 다른 실례는 데이타 구조에 기록함으로써 그의 존재를 신호로 보낸다.

다른 접속 정보가 저장되어 있지 않은 실시예의 경우에, 어느 순간에 캐시될 수 있는 접속의 수가 미리 정해지는 한계는 설정될 수 있다. 이 실시예에서, 실례들의 등록이 캐시된 접속의 과잉수를 야기시키면, "캐시된" 접속들 중 하나는 제거되어, 그 접속과 관련된 파라미터 핸들러(40) 증명은 종료되어야 한다는 것으로 인식된다. 종료 전, 파라미터 핸들러(40)는 종료되어야 하는 관련된 네트워크 실행부(50)를 인식한다. 순차적으로, 네트워크 실행부(50)는 서버가 어플리케이션 프로그램(62')을 호스팅한 상태에서 그의 세션(session)을 닫은 후 종료한다.

다른 정보가 저장된 실시예에서, 추가 정보는 캐시된 접속을 더욱 효과적으로 관리하도록 사용될 수 있다. 예를 들어, 사용자가 미리정해진 시간, 예를 들면 10분 내에 HTML 페이지(64')를 능동적으로 고찰하지 않으면, 파라미터 핸들러(40) 증명은 종료하도록 지시되어, 호스팅 서버의 세션은 종료되고, 파라미터 핸들러(40)는 레지스트리 내의 엔트리를 제거한다.

캐시된 접속 정보는 어떤 공지된 캐시 관리 계획을 사용하여 관리될 수 있다. 접속 엔트리는 "선입선출" 이론에 근거하여 폐기되어, 오래된 엔트리는 새로운 엔트리가 첨가될 때마다 폐기된다. 대안으로, 캐시된 접속 정보 엔트리는 "최저사용빈도" 이론에 근거하여 폐기되어, 사용자에 의해 최소량이 사용된 접속에 관련된 정보를 폐기한다. 랜덤 교체와 같은, 다른 캐시 관리 기술도 사용될 수 있다.

윈도우 사용자가 캐시된 접속을 갖는 이전 HTML 페이지(64')로 복귀하면, HTML 페이지(64')와 관련된 네트워크 실행부(50)는 전경(foreground)으로 복귀되어, "집중"을 다시 얻고, 관련된 어플리케이션의 진행이 보통 우선순위 레벨에서 시작한다. 필요하다면, 네트워크 실행부(50)는 어플리케이션(62')과의 접속을 재설정한다. 출력 데이타가 캐시된 접속에 적합한 네트워크 실행부(50)에 의해 저장되지 않아도, 접속이 어플리케이션 윈도우(66')에 적합하게 재설정되자마자 어플리케이션(62')에 대한 접속은 재설정되고 어플리케이션(10)은 어플리케이션 윈도우(66')에 직접 재기록한다.

유사하게, 상술된 접속 방법이 해석언어로 기록된 어플리케이션의 원격 실행을 제공하도록 사용될 수 있다. 다시 도 2를 참조하면, 클라이언트노드(24)는 클라이언트노드(24)를 위하여 어플리케이션(62)을 실행하는 서버노드(34)에 접속된다. 이 예에서, 서버 어플리케이션(62)은 클라이언트노드(24)가 해석언어로 기록된 어플리케이션을 리퀘스트하도록 허용하는 어플리케이션이다. 예를 들어, 어플리케이션(62)은 클라이언트노드(24)가 URL 어드레스를 사용하는 JAVA 어플리케이션을 다운로드하도록 허용하는 웹브라우저일 수 있다. 언급된 바와 같이, 어플리케이션이 다운로드되는 노드와 서버노드(34)는 컴퓨터 네트워크에 의해 상호접속된 분리 머신이다. 그러나, 몇몇 실시예에서, 이들 머신은 동일한 하나일 수 있다.

클라이언트노드(24)가 클라이언트 메모리와 프로세서 사용지침의 양쪽 용어에서 금지될 수 있는 다운로드된 어플리케이션을 저장하고 실행하도록 요구하는 것을 방지하기 위하여, 클라이언트노드(24)가 관련된 서버노드(34) 상의 실행환경(96)은 다운로드된 어플리케이션에 적합한 실행환경을 제공한다. 실횅환경은 다운로드된 어플리케이션의 바이트 스트림을 해석하여 어플리케이션을 나타내는 일련의 명령어를 생성한다. 어플리케이션이 JAVA 해석언어로 기록되어 있으면, 실행환경은 대체로 "가상 JAVA 머신"으로 칭해진다.

몇몇 실시예에서, 실행환경은 콤파일러를 포함한다. 이들 콤파일러는 어플리케이션의 바이트 스트림을 "고유" 모드로 변환시킨다. 예를 들어, 콤파일러는 JAVA 어플리케이션 언어로 기록된 어플리케이션의 바이트 스트림을 80486 머신 코드로 변환시킨다. 해석언어 바이트 스트림을 고유 코드로 변환하는 것은 각 바이트가 실시간에 해석되고 실행되어야 하는 경우보다 어플리케이션을 더 빠르게 실행하도록 허용한다. 몇몇 콤파일러는, 그러나, 어플리케이션이 실행하는 동안 바이트 스트림을 콤파일할 수 있다. 이들 콤파일러는 때때로 "바로 제시간"(just in time) 콤파일러로서 언급되고, 보통 콤파일된 코드의 정적 스트림을 생성하기 위하여 현재-실행 지시를 실행하기 전에 미리정해진 수의 바이트를 고찰한다.

다운로드된 어플리케이션은 서버노드(24)에 의해 해석되고 실행되며, 어플리케이션의 출력은, 도 2와 관련해서 설명된 바와 같이, 클라이언트노드로 전송된다. 또한, 서버노드(34)는 클라이언트노드(24)로부터의 입력을 수신한다. 이것은 클라이언트노드(24)가 다운로드된 어플리케이션을 조절하거나 또는 입력을 어플리케이션에 제공하도록 허용한다. 서버노드(34)는 다운로드된 어플리케이션을 해석하고 실행시키도록 개별 실행환경을 설정한다. 이들 실시예에서, 다운로드된 어플리케이션과 관련된 실행환경은 그 출력을 먹스(mux; 121)로 향하게 할 것이다.

도 6을 참조하면, 어떤 클라이언트(24, 24', 24"), 또는 사실상 어플리케이션(63)을 갖는 서버(34)에 부착된 모든 클라이언트(일반적으로 24)는 다른 서버(34', 34")일 수 있다는 것을 인식해야 한다. 이 방식에서, 어플리케이션(63)에 의해 전송된 데이타는 클라이언트노드(24)로 보내지기 전에 다른 서버로 보내진다. 이 방식에서, 어플리케이션(63)에 의해 전송된 데이타는 이 네트워크가 팬아웃할 때 수가 증가된 클라이언트노드로 전송된다.

각 클라이언트(24)가 서버(34)와의 접속을 종료할 때, 각 클라이언트 프로토콜 스택(일반적으로 104)과 이에 관련된 최소 스택(일반적으로 107)은 파괴된다. 유사하게, 제1클라이언트 프로토콜 스택(104)와 관련된 최소 프로토콜 스택(일반적으로 106)도 파괴된다. 최소(107)의 지속과 제2(및 부수)클라이언트 프로토콜 스택(104)이 종료될 때, 구성은 실행환경(96)과 관련된 제1클라이언트 통신프로토콜 스택(104)과 마찬가지이다. 모든 제2 및 부수클라이언트 프로토콜 스택(104)이 종료될 때까지, 제1클라이언트 프로토콜 스택(104)은 파괴되지 않고 심지어 제1클라이언트(24)는 더이상 존재하지 않는다는 것을 인식해야 한다.

도 2에 도시된 바와 같이, 각 실행환경(96)은 다중장치(121, 121', 121")를 통해 각 프로토콜 스택(104)과 통신한다. 이제 본 발명에 따른 도 6을 참조하면, 예를 들어 서버(34)로부터 데이타 전송을 섀도우하거나 모니터하기 위하여 또는 주식시세 어플리케이션과 같이 동일 데이타가 다수의 클라이언트(일반적으로 24)에 실질적으로 동시에 동시전송되거나 전송되는 특정 동시전송 어플리케이션으로부터 데이타를 동시전송하기 위하여, 하나 이상의 클라이언트가 제1클라이언트(24)로 전송되려는 데이타를 수신하는 것이 가능하다.

이러한 경우에, 제1클라이언트(24)는 특정 어플리케이션(63)이 상술된 바와 같이데이타를 실행하고 클라이언트(24)로 전송하도록 야기시킨다. 제2클라이언트(24')가 동시전송 어플리케이션(63)으로 억세스을 리퀘스트할 때, 접속관리기(80)는 제1클라이언트(24)와 관련하여 이미 설명된 바와 같이, 제2클라이언트(24')에 적합한 프로토콜 스택(104')을 구축하기 시작한다. 그러나, 어플리케이션(63)이 동시전송 어플리케이션이기 때문에, 접속관리기(80)는 추가 실행환경(96)을 개시할 필요가 없고 대신 동시전송 어플리케이션(63)으로부터 제2클라이언트(24')와 다른 추가 클라이언트(24")에 데이타를 전송하는 데 필요한 스텝을 취한다는 것을 인식한다.

먼저, 접속관리기(80)는 제1클라이언트(24)의 통신프로토콜 스택(104)과 관련되는 제1최소 통신프로토콜 스택(106)을 형성한다. 접속관리기(80)는 다음에 제2클라이언트(24')의 통신프로토콜 스택(104')과 관련된 제2최소 통신프로토콜 스택(106')을 형성한다. 각 추가의 클라이언트(24")가 동시전송 어플리케이션(63)으로 억세스을 리퀘스트함에 따라, 다른 최소 프로토콜 스택(106')은 제1클라이언트 프로토콜 스택(104)과 관련되어 생성되고 및 다른 최소 프로토콜 스택(107') 및 클라이언트 프로토콜 스택(104")은 각 신규 클라이언트(24")에 적합하게 생성된다. 제1클라이언트 프로토콜 스택(104) 및 제1클라이언트 프로토콜 스택(104)에 관련된 모든 최소 프로토콜 스택(106, 106')과, 클라이언트 프로토콜 스택(104', 104")의 각 쌍 및 각 추가의 클라이언트(24', 24")에 관련된 최소 프로토콜 스택(107, 107')은 다중장치(121)를 경유하여 통신하게 된다.

다중장치(121)가 단지 하나의 클라이언트(24)에 데이타를 향하게 하거나 또는 이로부터 수신할 때, 다중장치(121)는 단순 관통장치로서 작용한다. 그러나, 단일 어플리케이션(63)으로부터 데이타를 수신하거나 또는 이에 전송하는 하나 이상의 클라이언트(24, 24', 24")가 있으면, 각 다중장치(일반적으로 121)는 두개의 추가 구성을 취한다. 하나의 구성에서, 다중장치(121')는 제1클라이언트 프로토콜 스택(104)과 이에 관련된 각각의 최소 통신프로토콜 스택(106, 106')에 어플리캐이션 데이타를 전송하고 이로부터 데이타를 수신하도록 구성된다. 다른 구성에서, 다중장치(121")는 최소 프로토콜 스택(107, 107')에 의해 수신된 데이타를 이와 관련된 클라이언트 프로토콜 스택(104', 104")에 각각 전송하도록 구성된다. 이 실시예에서, 먹스(121)는 각 클라이언트 프로토콜 스택(104, 104', 104")로부터 입력데이타를 직접 수신할 수 있다.

접속관리기(80)는 제1클라이언트(24)와 관련된 최소 프로토콜 스택(106, 106')과 제2클라이언트(24') 및 부속클라이언트(24")의 최소 프로토콜 스택(107, 107') 각각에 접속시키고, 다중장치(121)가 어플리케이션(63)으로부터 출력을 제1클라이언트(24)의 통신프로토콜 스택(104) 및 이와 관련된 최소 프로토콜 스택(106, 106')에 전송하도록 지시한다. 다중장치(121)는 또한 각 제2 및 부속의 클라이언트 최소 프로토콜 스택(107, 107')을 이와 관련된 각각의 클라이언트 프로토콜 스택(104, 104')에 접속시키도록 접속관리기(80)에 의해서 지시된다. 그러므로, 제1클라이언트 프로토콜 스택(104)을 경유하여 제1클라이언트(24)로 전송된 데이타는 각각의 관련된 프로토콜 스택(104', 104")과 각각의 관련된 최소 프로토콜 스택(107, 107')을 경유하여 제1클라이언트(24), 제2클라이언트(24') 및 부속 클라이언트(24")와 관련된 최소 프로토콜 스택(106, 106')로 전송된다. 일실시예에서, 프로토콜 스택 콘테이너는 트랙수와 주어진 어플리케이션(63)에 관련된 프로토콜의 형태를 유지하는 데이타 구조를 포함한다.

도 7을 참조하면, 상술된 바와 같이, 한 서버(34)의 "클라이언트"가 다른 서버(34', 34")(단순화를 위해 단지 두개만 도시됨)인 것이 가능하다. 그리고, 제2서버(34', 34")는 클라이언트(일반적으로 24) 또는 추가 서버에 데이타를 전송한다. 본 실시예에서, 서버 프로토콜 스택(일반적으로 104)의 출력은 제2서버(34', 34")의 프로토콜 스택(107')에 접속된다. 그리고, 상술된 바와 같이, 데이타는 프로토콜 스택과 클라이언트(일반적으로 24) 사이에 전송된다. 본 방식에서, 데이타는 하나의 서버에 의해서 지지될 수 있는 것보다 많은 클라이언트에 팬아웃되고 분배될 수 있다.

본 발명은 특정의 바람직일실시예를 참조하여 특별히 도시되고 설명되었지만, 본 발명의 당업자에 의해서 첨부된 청구범위에 의해 한정된 본 발명의 요지 및 사상으로부터 벗어남이 없이 형태 및 설명에서의 다양한 변경이 이루어질 수 있다는 것을 이해해야 한다.

Claims

다음방법으로 구성되는 클라이언트노드와 서버상에 실행되는 어플리케이션 프로그램사이의 통신방법.

(a) 클라이언트노드와 서버상에 위치한 예정된 통신 포트사이의 접속을 설정하는 단계;

(b) 엔드포인트 데이터 구조를 형성하는 단계;

(c) 상기 서버내의 클라이언트 스페이스를 상기 엔드포인트 데이터 구조와 연관시키는 단계;

(d) 상기 클라이언트 스페이스 및 상기 연관된 엔드포인트 데이터 구조와 연관된 프로토콜 스택을 발생시키는 단계;

(e) 상기 접속의 접속관리기를 통지하는 단계; 그리고

(f) 예정된 통신포트와 상기 클라이언트노드 사이의 접속을 상기 연관된 프로토콜 스택에 전송하는 단계;
제1항에 있어서, 다음의 단계를 더욱 포함하는 것을 특징으로 하는 클라이언트노드와 서버상에 실행되는 어플리케이션 프로그램사이의 통신방법.

(a-a) 마스터 네트워크 정보노드에 의하여 상기 클라이언트노드로부터 어플리케이션 리퀘스트를 수신하는 단계;

(a-b) 상기 마스터 네트워크 정보노드에 의하여 상기 클라이언트노드에 서버 어드레스를 제공하고, 상기 어플리케이션을 갖는 서버에 상기 예정된 포트 어드레스를 제공하는 단계;

(a-c) 제공된 어드레스에 기초한 예정된 포트에 접속하기 위하여 클라이언트노드로부터 리퀘스트를 상기 서버에 의하여 수신하는 단계;

(a-d) 클라이언트노드와 예정된 일반 포트사이의 접속을 설정하는 단계;
제1항에 있어서, 상기 (c)단계는 실행환경에 상기 엔드포인트 데이터 구조를 제공하는 가상 머신을 연관시키는 단계를 더욱 포함하는 것을 특징으로 하는 클라이언트노드와 서버상에 실행되는 어플리케이션 프로그램사이의 통신방법.
제1항에 있어서, 연관된 프로토콜 스택상에 발생된 엔드포인트 데이터 구조를 푸싱하는 단계를 더욱 포함하는 것을 특징으로 하는 클라이언트노드와 서버상에 실행되는 어플리케이션 프로그램사이의 통신방법.
프로그램 수단에서 구체화된 클라이언트노드와 통신하기 위한 컴퓨터 판독 프로그램을 갖는 물품의 제조방법에서, 상기 물품은,

예정된 포트를 거쳐 클라이언트노드와 접속을 설정하기 위한 컴퓨터 판독 프로그램 수단과;

엔드포인터 데이터 구조를 형성하기 위한 컴퓨터 판독 프로그램 수단과;

엔드포인트 데이터 구조와 메모리 스페이스를 연관하기 위한 컴퓨터 판독 프로그램 수단과;

메모리 스페이스 및 연관된 엔드포인트 데이트 구조와 연관된 프로토콜 스택을 발생시키는 컴퓨터 판독 프로그램 수단과;

예정된 포트와 클라이언트노드사이의 접속의 접속관리기를 통지하기 위한 컴퓨터 판독 프로그램 수단과;

예정된 포트와 클라이언트노드사이의 접속을 연관된 프로토콜 스택에 전달하기 위한 컴퓨터 판독 프로그램 수단으로 이루어지는 것을 특징으로 하는 물품.
제5항에 있어서, 클라이언트노드로부터 어플리케이션 리퀘스트를 수신하기 위한 컴퓨터 판독 프로그램 수단과; 서버 어드레스와 예정된 포트 어드레스를 클라이언트노드에 제공하기 위한 컴퓨터 판독 프로그램 수단과; 제공된 어드레스에 기초하여 예정된 포트에 접속하기 위하여 클라이언트노드로부터 리퀘스트를 수신하기 위한 컴퓨터 판독 프로그램 수단과; 클라이언트노드와 예정된 포트사이의 접속을 설정하기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 물품.
제5항에 있어서, 실행 환경에 상기 엔드포인터 데이터 구조를 제공하는 가상 머신을 연관시키기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 물품.
제5항에 있어서, 클라이언트노드에 프로토콜 조회를 발행하기 위한 컴퓨터 판독 프로그램 수단과; 클라이언트노드의 응답에 기초하는 엔드포인트 데이터 구조를 발생하기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 물품.
예정된 통신 포트를 갖는 서버노드와;

상기 클라이언트노드와 상기 서버노드의 예정된 통신 포트사이의 접속을 설정하는 통신 장치를 갖는 클라이언트노드와;

상기 서버노드상에 위치되고, 엔드포인트 데이터 구조를 포함하는 프로토콜 스택과;

상기 서버노드상의 메모리에 위치되고, 상기 프로토콜 스택과 연관되는 클라이언트 스페이스와;

상기 서버노드상에 위치된 통신관리기와;

상기 서버노드상에 위치되고, 상기 클라이언트노드와 상기 예정된 통신 포트사이의 상기 접속의 상기 접속관리기를 통지하는 통지 장치로 구성되고,

상기 통신관리기는 예정된 통신 포트와 상기 클라이언트노드사이의 접속을 상기 프로토콜 스택에 전달하는 클라이언트노드와 통신하기 위한 시스템.
제9항에 있어서, 다중장치를 더 포함하고,

상기 서버는 복수개의 프로토콜 스택으로 이루어지고, 상기 다중장치는 상기 다수의 프로토콜 스택의 각 프로토콜 스택과 소통하는는 것을 특징으로 하는 시스템.
제10항에 있어서, 상기 다중장치는 링크된 일련의 프로토콜 스택으로 이루어지고, 각 프로토콜 스택은 클라이언트노드와 접속을 유지하는 것을 특징으로 하는 시스템.
제11항에 있어서, 상기 프로토콜 스택은 드라이버가 스택상으로 푸쉬되어지게 허용하도록 구성되는 것을 특징으로 하는 시스템.
(a) 어플리케이션의 실행을 신호전송하는 입력신호를 클라이언트로부터 수신하는 단계;

(b) 실행 어플리케이션이 디스플레이되어질 수 있는 윈도우의 파라미터를 결정하는 단계;

(c) 결정된 파라미터를 사용하여 HTML 페이지에 통신 채널을 형성하는 단계;

(d) 통신 채널을 통하여 어플리케이션 윈도우내에서 서버상에서 실행하는 어플리케이션의 출력을 디스플레이하는 단계로 이루어진 HTML 페이지에서 실행 어플리케이션을 디스플레이하기 위한 방법.
제13항에 있어서, 상기 (a)단계는,

(a-a) 어플리케이션의 실행을 신호전송하기 위한 적어도 하나의 HTML 태그를 포함하는 HTML 페이지를 클라이언트에 디스플레이하는 단계와;

(a-b) 사용자에 의하여 적어도 하나의 HTML 태그의 선택에 응답하여 서버상에서 어플리케이션의 실행을 야기하는 단계로 이루어진 방법.
제13항에 있어서, 상기 (b)단계는 실행 어플리케이션이 디스플레이되어질 수 있는 윈도우의 파라미터를 결정하기 위하여 HTML 페이지가 저장된 파일을 억세스하는 단계로 이루어진 방법.
제15항에 있어서, 상기 (b)단계는 어플리케이션의 실행과 연관된 파라미터를 결정하기 위하여 HTML 페이지가 저장되는 파일을 억세스하는 단계를 더 포함하는 방법.
제13항에 있어서, 상기 (c)단계는 실행 어플리케이션과 HTML 페이지내의 어플리케이션 윈도우사이의 데이터 파이프를 형성하는 단계를 포함하는 방법.
HTML 페이지내에 어플리케이션 실행 윈도우와 연관된 파라미터를 수신하는 파라미터 핸들러와;

상기 파라미터 핸들러로부터 파라미터를 수신하고, 어플리케이션이 서버상에서 실행하도록 야기시키고, 상기 파라미터 핸들러로부터 수신된 파라미터에 응답하는 어플리케이션 실행 윈도우내의 어플리케이션의 실행을 디스플레이하는 네트워크 실행부로 이루어지는 HTML 페이지 내의 실행 어플리케이션을 디스플레이하기 위한 장치.
제18항에 있어서, HTML 페이지내에서 어플리케이션 실행 윈도우와 연관하는 파라미터를 결정하기 위하여 HTML 페이지를 저장하는 파일을 억세스하는 파라미터 핸들러를 더욱 포함하는 것을 특징으로 하는 장치.
제18항에 있어서, 파라미터 핸들러로부터 네트워크 실행부에 의하여 수용된 파라미터의 하나는 요청되어진 어플리케이션을 호스트하는 서버의 식별자인 것을 특징으로 하는 장치.
제18항에 있어서, 상기 네트워크 실행부는 요청되어진 어플리케이션을 호스팅하는 서버와 통신채널을 설정하는 것을 특징으로 하는 장치.
(a) HTML 페이지에서 어플리케이션의 실행을 신호전송하기 위하여 클라이언트로부터 입력을 수신하기 위한 컴퓨터 판독 코드수단;

(b) 실행 어플리케이션이 디스플레이되어질 수 있는 윈도우의 파라미터를 결정하기 위한 컴퓨터 판독 코드수단;

(c) 결정된 파라미터를 사용하여 HTML 페이지에 통신 채널을 형성하기 위한 컴퓨터 판독 코드수단;

(d) 통신 채널을 통하여 어플리케이션 윈도우내에서 서버상에 실행되는 어플리케이션의 출력을 디스플레이하기 위한 컴퓨터 판독 코드수단으로 이루어진 내장된 HTML페이지에서 실행 어플리케이션을 디스플레이하기 위한 컴퓨터 판독 코드수단을 갖는 물품의 제조물품.
(a) 제1HTML 페이지에서 어플리케이션의 실행을 신호전송하기 위하여 클라이언트로부터 입력을 수신하는 단계;

(b) 실행 어플리케이션이 디스플레이되어질 수 있는 윈도우의 파라미터를 결정하는 단계;

(c) 결정된 파라미터를 사용하여 제1HTML 페이지에 통신 채널을 형성하는 단계;

(d) 통신 채널을 통하여 어플리케이션 윈도우내에서 서버상에 실행되는 어플리케이션의 출력을 디스플레이하는 단계;

(e) 제2HTML 페이지의 디스플레이를 신호전송하기 위하여 클라이언트로부터 입력을 수신하는 단계와;

(f) 상기 제1HTML 페이지와 연관된 결정된 파라미터를 저장하는 단계로 이루어진 HTML 페이지 내의 실행 어플리케이션을 디스플레이하는 방법.
제23항에 있어서,

(g) 상기 제1HTML 페이지를 다시 디스플레이하기 위하여 사용자로부터 입력을 수신하는 단계;

(h) 상기 제1HTML 페이지와 연관된 저장된 파라미터를 수신하는 단계;

(i) 회수된 연관파라미터에 응답하여 실행 어플리케이션을 디스플레이하는 윈도우를 포함하는 제1HTML 페이지를 다시 디스플레이하는 단계를 더 포함하는 방법.
어플리케이션 프로그램을 저장하고 실행하는 서버와;

어플리케이션 프로그램의 실행을 개시하기 위하여 상기 서버에 명령을 보내고, 상기 서버상에서 실행되는 어플리케이션 프로그램으로부터 출력을 받고, 더 나아가 어플리케이션 프로그램 출력을 전송하는 네트워크 실행부;

파라미터를 받고, 상기 네트워크 실행부에 접수된 파라미터를 패스하는 파라미터 핸들러;

상기 파라미터 핸들러내 윈도우 파라미터를 패스하는 어플리케이션 윈도우를 포함하고 상기 네트워크 실행부로부터 어플리케이션 출력을 받는 HTML 파일로 이루어진 것을 특징으로 하는 HTML 파일내에 어플리케이션을 내장하기 위한 시스템.
제25항에 있어서, 상기 HTML 파일내에 내장되었을 때, 상기 파라미터 핸들러에 윈도우 파라미터를 패스하는 어플리케이션 윈도우가 디스플레이되어지게 하며, 상기 네트워크 실행부로부터 어플리케이션 프로그램 출력을 수신하는 HTML 태그를 욱 포함하는 것을 특징으로 하는 시스템.
(a) 제1클라이언트노드와 상기 서버노드상의 제1클라이언트 프로토콜 스택사이의 접속을 제공하는 단계;

(b) 상기 서버노드상에서 실행되는 어플리케이션과 상기 제1클라이언트 프로토콜 스택사이의 접속을 제공하는 단계;

(c) 상기 서버노드상에서 실행되는 어플리케이션과 제1최소 통신 프로토콜 스택 사이의 접속을 제공하는 단계;

(d) 제2클라이언트노드와 상기 서버노드상의 제2클라이언트 프로토콜 스택사이의 접속을 제공하는 단계;

(e) 상기 제1최소 프로토콜 스택과 제2최소 프로토콜 스택사이의 접속을 제공하는 단계;

(f) 상기 제2최소 프로토콜 스택과 상기 제2클라이언트 프로토콜 스택사이의 접속을 제공하는 단계;

(g) 상기 어플리케이션 프로그램에서 상기 제1클라이언트 프로토콜 스택과 상기 제1최소 프로토콜 스택으로 거의 동시에 데이터를 전송하는 단계로 이루어진 서버노드상에서 실행되는 어플리케이션으로부터 동일 데이타를 일반화된 리시버 프로그램을 각각 실행하는 최소한 두개의 클라이언트노드로 거의 동시에 전송하는 방법.
제27항에 있어서, 상기 제1클라이언트 프로토콜 스택과 상기 어플리케이션 프로그램 사이의 접속은 다중장치를 통하여 일어나도록 하는 것을 특징으로 하는 방법.
제27항에 있어서, 상기 제1최소 프로토콜 스택과 상기 어플리케이션 프로그램 사이의 접속은 다중장치를 통하여 일어나도록 하는 것을 특징으로 하는 방법.
제27항에 있어서, 상기 제2클라이언트 프로토콜 스택과 상기 제2최소 프로토콜 스택사이의 접속은 다중장치를 통하여 일어나도록 하는 것을 특징으로 하는 방법.
제27항에 있어서, 상기 제1최소 통신 프로토콜 스택과 상기 제1클라이언트 프로토콜 스택과 연관하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
제27항에 있어서, 상기 제2최소 통신 프로토콜 스택과 상기 제2클라이언트 프로토콜 스택과 연관하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
제27항에 있어서, 상기 어플리케이션 프로그램이 브로드캐스트에 적합한 지 여부를 결정하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
어플리케이션 프로그램,

상기 어플리케이션 프로그램과 전기통신하는 제1클라이언트 프로토콜 스택,

상기 어플리케이션 프로그램과 전기통신하는 제1최소 프로토콜 스택,

상기 제1최소 프로토콜 스택과 전기통신하는 제2최소 프로토콜 스택,

상기 제2최소 프로토콜 스택과 전기통신하는 제2클라이언트 프로토콜 스택,

상기 제1클라이언트 프로토콜 스택과 전기통신하는 제1클라이언트, 그리고

상기 제2클라이언트 프로토콜 스택과 전기통신하는 제2클라이언트와로 이루어진 서버노드를 구비하여,

상기 어플리케이션 프로그램으로부터의 데이터가 상기 제1클라이언트 프로토콜 스택과 제1최소 프로토콜 스택에 거의 동시에 전송되어지는 것을 특징으로 하는 통신시스템.
(a) 클라이언트노드에 의하여 이루어진 리퀘스트에 응답하여 서버노드에 어플리케이션을 다운로딩하는 단계;

(b) 클라이언트노드와 서버상에 위치한 예정된 토인 포트사이의 접속을 설정하는 단계;

(c) 엔드포인트 데이터 구조를 형성하는 단계;

(d) 엔드포인트 데이터 구조와 서버에 의하여 호스트되는 클라이언트 스페이스를 연관하는 단계;

(e) 클라이언트 스페이스 및 연관된 프로토콜 스택과 연관된 엔드포인트 데이터 구조를 발생하는 단계;

(f) 접속의 접속관리기를 통지하는 단계; 그리고

(g) 예정된 통신 포트와 클라이언트노드사이의 접속을 연관된 프로토콜 스택에 전달하는 단계로 이루어지는 해석언어로 기록된 어플리케이션을 원격적으로 실행하기 위한 방법.
제35항에 있어서, 상기 (b)단계는,

(b-a) 마스터 네트워크 정보노드에 의하여 상기 클라이언트노드로부터 어플리케이션 리퀘스트를 받는 단계;

(b-b) 마스터 네트워크 정보노드에 의하여 클라이언트노드에 서버 어드레스를 제공하고 다운로드된 어플리케이션을 갖는 서버에 에정된 포트 어드레스를 제공하는 단계;

(b-c) 제공된 어드레스에 기초하여 예정된 포트에 접속하기 위하여 클라이언트노드로부터 요청을 서버에 의하여 받는 단계;

(b-d) 클라이언트노드와 예정된 제너럴 포트사이의 접속을 설정하는 단계로 이루어지는 해석언어로 기록된 어플리케이션을 원격적으로 실행하기 위한 방법.
제35항에 있어서, 상기 (d)단계는 엔드포인트 데이터 구조와 연관된 실행 환경을 제공하는 가상 머신을 연관하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 (d)단계는 엔드포인트 데이터 구조와 연관된 실행 환경을 제공하는 가상 자바 머신을 연관하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
제35항에 있어서, 연관된 프로토콜 스택으로 발생된 엔드포인트 데이트 구조를 푸싱하는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
제35항에 있어서, 클라이언트노드로부터 입력을 받아들이는 단계를 더욱 포함하는 것을 특징으로 하는 방법.
클라이언트노드에 의하여 만들어진 요청에 응답하여 서버노드에 어플리케이션을 다운로딩하기 위한 컴퓨터 판독 프로그램 수단과;

클라이언트노드와 서버상에 위치한 예정된 통신포트사이의 접속을 설정하기 위한 컴퓨터 판독 프로그램 수단과;

엔드포인트 데이터 구조를 형성하기 위한 컴퓨터 판독 프로그램 수단과;

엔드포인트 데이터 구조와 서버에 의하여 호스트되는 클라이언트 스페이스를 연관하기 위한 컴퓨터 판독 프로그램 수단과;

클라이언트 스페이스와 연관된 프로토콜 스택과 연관된 엔드포인트 구조를 발생하기 위한 컴퓨터 판독 프로그램 수단과;

접속의 접속관리기를 통지하기 위한 컴퓨터 판독 프로그램 수단과;

예정된 통신 포트와 클라이언트노드사이의 접속을 연관된 프로토콜 스택에 전달하기 위한 컴퓨터 판독 프로그램 수단으로 이루어진 해석언어로 기록된 어플리케이션을 원격적으로 실행하기 위하여 구체화된 컴퓨터 판독 프로그램 수단을 갖는 제조물품.
제41항에 있어서, 클라이언트노드로부터 어플리케이션 리퀘스트를 받기 위한 컴퓨터 판독 프로그램 수단과;

클라이언트노드에 서버 어드레스와 예정된 포트 어드레스를 제공하기 위한 컴퓨터 판독 프로그램 수단과;

제공된 어드레스에 기초하여 예정된 포트에 접속하기 위하여 클라이언트노드로부터 요청을 받기 위한 컴퓨터 판독 프로그램 수단과;

클라이언트노드와 예정된 포트사이의 접속을 설정하기 위한 컴퓨터 판독 프로그램 수단으로 이루어진 것을 특징으로 하는 제조물품.
제41항에 있어서, 실행 환경에 엔드포인트 데이터 구조를 제공하는 가상 머신을 연관하기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 제조물품.
제41항에 있어서, 클라이언트노드에 프로토콜 조회을 발행하기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 제조물품.
제40항에 있어서, 클라이언트로부터 입력을 수신하기 위한 컴퓨터 판독 프로그램 수단을 더욱 포함하는 것을 특징으로 하는 제조물품.
예정된 통신 포트를 갖는 서버노드;

클라이언트노드와 상기 서버노드의 예정된 통신 포트사이의 접속을 설정하기 위한 통신 장치를 갖는 클라이언트노드;

엔드포인트 데이터 구조를 포함하고 상기 서버노드상에 위치한 프로토콜 스택;

해석언어로 기록된 어플리케이션을 위한 동적 번역 환경을 제공하고 상기 프로토콜 스택과 연관하는 상기 서버노드상의 메모리에 위치한 클라이언트 스페이스;

상기 서버노드에 위치한 통신관리기; 그리고

상기 클라이언트노드와 상기 예정된 통신 포트사이의 접속의 접속관리기를 통지하는 상기 서버노드에 위치한 통지 장치로 이루어지고,

상기 통신관리기는 상기 예정된 통신 포트와 상기 클라이언트노드사이의 상기 접속을 상기 프로토콜 스택에 전달하는 것을 특징으로 하는 해석언어로 기록된 어플리케이션을 원격적으로 실행하기 위한 시스템.
제46항에 있어서, 복수의 프로토콜 스택의 각각과 통신하는 다중장치를 더욱 포함하는 것을 특징으로 하는 시스템.
제46항에 있어서, 상기 다중장치는 링크된 일련의 프로토콜 스택을 포함하고, 각 프로토콜 스택은 클라이언트노드와 접속을 유지하는 것을 특징으로 하는 시스템.
제46항에 있어서, 상기 프로토콜 스택은 드라이버가 스택상으로 푸쉬되어지는 것을 허용하도록 구조화된 것을 특징으로 하는 시스템.