KR20140038988A

KR20140038988A - 효율적 상태 조정 기법

Info

Publication number: KR20140038988A
Application number: KR1020137033213A
Authority: KR
Inventors: 크리스토퍼 로버트 헤이워드
Original assignee: 마이크로소프트 코포레이션
Priority date: 2011-06-15
Filing date: 2012-06-10
Publication date: 2014-03-31
Also published as: WO2012173898A3; CN103597465A; EP2721506A4; JP2014523568A; US20120323990A1; EP2721506A2; WO2012173898A2

Abstract

여기에 기술된 실시예들은 일반적으로 상태 업데이트들에 대한 롱 폴링 요청의 양방향 파라미터로서 토큰을 이용하는 방법 및 시스템에 관한 것이다. 클라이언트는 상태 업데이트들에 대해 서버를 폴링하는데, 이때 업데이트들은 서버 이벤트의 결과일 수 있다. 현재 상태 데이터를 나타내는 토큰/해시를 생성하기 위해 서버 상태 데이터가 해싱된다. 서버는 이러한 토큰/해시를 폴링 요청함에 있어 클라이언트로부터 수신된 토큰/해시와 비교한다. 토큰들이 상이한 경우, 서버는 서버 토큰과 함께 실제 상태 데이터를 클라이언트로 보낸다. 요청 파라미터들로서 토큰들을 사용함으로써, 불필요한 상태 업데이트들이 회피되고, 데이터의 푸쉬를 상태 업데이트들에 국한함으로써 클라이언트/서버 동기가 보다 빠르게 이루어진다. 또한 클라이언트는 토큰 요청 파라미터에 대한 빈 값 또는 무작위/디폴트 값을 전송함으로써 폴링에 대한 응답을 강제할 수 있다.

Description

효율적 상태 조정 기법{EFFICIENT STATE RECONCILIATION}

웹 서버들과 같은 서버들로부터 데이터를 요청하는 웹 브라우저들과 같은 브라우저들에 의한 폴링(polling)의 사용이 점점 일반화되어 왔다. 웹 브라우저들 및 웹 서버들 사이의 데이터 교환에 있어서, 웹 브라우저나 클라이언트는 통상적으로 클라이언트 및 서버 사이의 동기화를 달성하기 위한 시도로 콘텐츠 업데이트에 대한 요청을 서버로 보낸다. 각각의 요청에 응답하여, 서버는 완성된 응답을 보낸다. 각각의 시점에 완성된 응답을 보냄으로써, 그러한 요청 및 응답 교환은 서버에서 데이터에 대한 아무런 업데이트도 이뤄지지 않은 경우에도 클라이언트 요청에 대한 응답으로 데이터가 전송되는 한 네트워크 자원들을 불필요하게 소비한다. 또한, 하나의 웹 서버와 통신하는 수많은 브라우저들로부터의 웹 서버 콘텐츠 및 업데이트들에 대한 증가하는 수요가 시스템 자원들 및 그에 따른 대기시간들에 대한 부담을 일으키며, 그것은 클라이언트 콘텐츠를 서버 업데이트들과 조정하고자 시도함에 있어 비효율성을 가중시킨다.

브라우저들 및 서버들 사이에서 콘텐츠를 보다 효율적을 교환하고자 하는 시도함에 있어, 하이퍼텍스트 전송 프로토콜(HTTP) 롱 폴링(long polling)과 같은 롱 폴링이 웹 서버에서의 이벤트 또는 서버 동작을 일으키는 다른 이벤트가 발생할 때 웹 서버가 브라우저로 데이터를 푸쉬할 수 있게 해준다. 롱 폴링을 사용하여, 브라우저나 클라이언트는 서버에서의 이벤트들을 획득하라는 롱 폴링 요청을 서버에 전송한다. 그러한 롱 폴링 기법들은 종종 브라우저가 데이터를 특별하게 요청하지 않으면서 서버로부터 브라우저로 그러한 데이터를 푸쉬하기 위해 오래 유지되는 HTTP 요청들을 이용하기 위한 "카밋(Comet)" 웹 애플리케이션 모델의 일부로 지칭된다. 통상적인 롱 폴링 또는 카밋 구현예들에서, 클라이언트 요청들은 서버 이벤트가 일어날 때까지 서버에 의해 유지된다. 이벤트가 일어날 때, 서버는 새로운 데이터를 완성된 응답으로서 브라우저로 전송한다. 따라서, 서버로의 요청은 서버가 전송할 새로운 데이터를 가질 때까지 지속된다. 응답 수신 시, 브라우저는 후속 이벤트를 기다리라는 또 다른 요청을 서버에 전송한다. 그러나, 각각의 서버 응답이 서버 이벤트에 해당하기 때문에 불필요한 업데이트들은 여전히 일어나며 동기에서 벗어난 클라이언트들은 서버와 콘텐츠를 조정함에 있어 대기시간을 경험한다. 이러한 서버 이벤트들의 일부는 서버가 중간 이벤트들에 기반하여 새 데이터를 전송하기 시작할 때 클라이언트가 이미 서버의 현재 상태와 동일한 상태일 때처럼 동기화 수행이 불필요하다. 결과적으로, 인터넷에 대한 연결 끊김으로 인해 클라이언트가 동가에서 벗어나는 경우, 예컨대 클라이언트는 이전의 서버 이벤트들에 대한 데이터와 함께 잠정적으로 수많은 응답 메시지들을 처리함으로써 현재의 서버 상태를 따라 잡고자 시도한다. 서버가 또 다른 변경을 이행하고 있던 동안 보통 느린 클라이언트는 이전 이벤트들을 아직도 처리하고 있기 때문에, 그러한 클라이언트가 빠르게 바뀌는 서버와 동기를 유지하기는 몹시 어려울 수 있다. 또한 클라이언트가 서버에 뒤쳐지는 경우, 클라이언트가 서버와 동기에 이르게 하기 위해 어떤 과도기 이벤트들은 무시될 수 있다. 그러나, 서버 이벤트들에 기반한 데이터 푸쉬는 서버의 현재 상태와의 궁극적 동기를 달성함에 있어 클라이언트에 대한 그들의 사용 부족과 무관하게 클라이언트에게 이벤트들을 푸쉬한다.

이 배경 부분에서 특정 문제들이 다루어지기는 했지만, 본 명세서는 결코 그러한 특정 문제들을 해결하는 데 국한되어서는 안된다.

실시예들은 일반적으로 토큰 메커니즘을 통해 서버에 있는 상태 데이터를 클라이언트로 푸쉬하는 것에 관한 것이다. 구체적으로, 토큰은 서버(들) 및 클라이언트(들) 사이의 효율적 상태 조정을 수행하기 위해 상태 업데이트들에 대한 롱 폴링 요청의 여러 방향, 예컨대 양방향 파라미터로서 사용된다. 웹 서버와 같은 서버가 상태 업데이트를 수신한다. 예컨대 서버는 문서 편집 세션을 포함하는 애플리케이션으로부터 상태 업데이트를 수신할 수 있고, 문서 편집 세션 중에 공동 집필 문서에 대한 변경이 이루어지고 예컨대 서버나 서버 상에서 실행되는 관리 모듈로 변경사항들이 보내진다. 그러면, 관리 모듈은 수신된 상태 업데이트를 반영하도록 서버의 상태를 변경한다. 그런 다음 서버는 서버와 클라이언트 사이에서 동기되기를 요망하는 상태의 다이제스트(digest)/해시를 계산한다. 그리하여, 해시 값을 포함하는 토큰이 생성된다. 어떤 상태 업데이트에 대해 클라이언트로부터 요청을 수신 시, 서버는 클라이언트 요청과 함께 수신된 토큰을 서버 상의 토큰과 비교하여 그 토큰들이 서로 다른지를 판단한다. 토큰들이 서로 상이하지 않다면, 클라이언트는 데이터의 현재 상태를 갖는 것이므로 서버와 자신의 콘텐츠를 추가 조정할 필요가 없다. 대신 서버는 서버 상태의 변화가 일어날 때까지 수신된 토큰과 함께 클라이언트 요청, 즉 장기 유지 요청을 계속 유지한다. 그러나 토큰들이 서로 다르다면, 클라이언트는 현재 상태를 갖지 못한 것이다. 그러면 서버는 서버 상의 현재 토큰과 함께 실제 상태를 클라이언트에 전송한다. 실시예들에서, 클라이언트는 그러면 자신의 데이터를 업데이트하고, 상태 업데이트에 대한 후속 요청과 함께 전송할 수신된 토큰을 저장할 수 있다. 설명했듯이, 실시예들에서 클라이언트로부터의 요청은 롱 폴링 기법의 일부인 장기 유지 요청이다. 또 다른 실시예들에서 클라이언트에 의한 롱 폴링은 HTTP 롱 폴링을 포함한다. 다른 실시예들에서는 정기적 폴링이 사용된다.

추가적 실시예들에서, 클라이언트는 서버가 상태 업데이트 요청에 대해 즉시 응답하도록 강요할 수 있다. 다른 실시예들에서 서버는 소정 시간 안에, 또는 예컨대 시스템 자원들의 가용성으로부터 판단컨대 서버가 응답할 수 있을 때, 응답해야 한다. 서버로 하여금 응답하도록 만들 때, 클라이언트는 일 실시예에 따라 자신의 장기 유지 요청(long-held request)안에 요청 파라미터로서 토큰 값에 대한 빈 값을 서버에 보낸다. 다른 실시예에서 클라이언트는 자신의 장기 유지 요청에 요청 파라미터로서 토큰 값에 대한 무작위/디폴트 값을 서버로 보내며, 이때 무작위/디폴트 값은 서버 상의 현재 토큰 값과 일치할 가능성이 없는 값이다. 빈 값 또는 무작위/디폴트 값은 서버가 서버 상의 토큰 및 클라이언트로부터 수신된 토큰이 일치하지 않는다고 판단하게 한다. 결과적으로 서버는 자신의 상태 데이터 및 서버 상의 토큰을 클라이언트로 전송함으로써 즉시 응답한다. 그에 따라 클라이언트는 서버가 주기적으로 데이터를 밀어 내거나 서버 이벤트가 발생하기를 기다리지 않고 자신의 폴링 요청에 대한 즉각적 응답을 얻을 수 있게 된다.

이 요약은 이하의 상세한 설명에 자세히 기술되는 개념들의 선택을 간략한 형식으로 소개하기 위해 제공된다. 이 요약은 청구된 발명 대상의 주요하고 필수적 특징을 드러내기 위한 것이 아니며 어떤 식으로든 청구된 발명 대상의 범위를 한정하기 위한 것도 아니다.

본 개시의 실시예들은 유사 참조번호들이 유사 항목들을 지칭하는 첨부 도면들을 참조하여 보다 용이하게 기술될 수 있다.
도 1a는 여기 개시된 실시예들에 따라 상태 업데이트에 대한 장기 유지 폴링 요청의 파라미터로서 토큰을 이용하는 환경 또는 시스템의 예시적인 논리적 표현을 도시한다.
도 1b는 여기 개시된 실시예들에 따라 상태 업데이트에 대한 장기 유지 폴링 요청의 파라미터로서 토큰을 이용하는 또 다른 유형의 환경 또는 시스템, 예컨대 3 계층 구조의 예시적인 논리적 표현을 도시한다.
도 2a는 본 개시의 실시예들에 따라 도 1a 및 1b에 도시된 예시적 환경들에서 상태 업데이트에 대한 장기 유지 폴링 요청의 파라미터로서 토큰을 이용하기 위한 소프트웨어 모듈들의 예시적인 논리적 표현을 도시한다.
도 2b는 본 개시의 실시예들에 따라 상태와 함께 요청 파라미터 및 응답 리턴 값으로서 토큰/해시를 이용하는 환경이나 시스템의 예시적인 논리적 표현을 도시한다.
도 3은 본 개시의 실시예들에 따라 상태 업데이트들을 푸쉬할지 여부를 결정하기 위한 프로세스의 동작 특성들을 도시한 흐름도를 예시한다.
도 4는 본 개시의 실시예에 따라 상태가 바뀌었는지를 판단하기 위해 토큰들을 비교하는 프로세스의 동작 특성들을 도시한 흐름도를 예시한다.
도 5는 본 개시의 실시예들에 따라 상태 업데이트에 대한 요청에 대한 응답을 강요하기 위한 프로세스의 동작 특성들을 도시한 흐름도를 예시한다.
도 6은 본 개시의 실시예에 따라 데이터를 푸쉬하기 위해 빈 값 또는 무작위/디폴트 토큰 값을 수신하기 위한 프로세스의 동작 특성들을 도시한 흐름도를 예시한다.
도 7은 본 개시의 실시예들이 구현될 수 있는 예시적 컴퓨팅 시스템을 도시한다.

지금부터 본 개시는 특정 실시예들이 도시된 첨부 도면들을 참조하여 보다 충분하게 예시적 실시예들을 설명할 것이다. 그러나 다른 양태들이 많은 다양한 형식들로 구현될 수 있으며, 이 개시에 특정 실시예들들을 포함시키는 것이 그러한 양태들을 여기 설명되는 실시예들로 한정하는 것으로 해석되지 않아야 한다. 그보다, 도면에 도시된 실시예들은 철저하고 완전하며 당업자에게 의도한 범위를 충분히 전달하는 개시를 제공하기 위해 포함되는 것이다. 점선들은 선택적인 구성 요소들이나 동작들을 도시하기 위해 사용될 수 있다.

실시예들은 일반적으로 서버 이벤트와 달리 데이터의 상태 변경에 기반하여 서버가 클라이언트나 브라우저로 데이터를 푸쉬하게 할 수 있는 롱 폴링을 이용한 토큰 메커니즘을 이용하는 것에 관한 것이다. 상태 업데이트들과 함께 서버 메시지들을 클라이언트로 보내는 것은 불필요한 데이터 교환을 피하게 함으로써 시스템 효율성을 개선시킨다. 예를 들어, 발표자가 웹 회의 환경에서 다양한 사용자들과 그들 각자의 웹 브라우저들로부터 프레젠테이션 슬라이드쇼를 공유하는 공동 저작 프레젠테이션 애플리케이션에서, 발표자는 슬라이드 #1에서 슬라이드쇼를 시작할 수 있다. 웹 브라우저 A의 클라이언트 A는 자신의 컴퓨터의 사용자 인터페이스 모듈을 통해 슬라이드 #1을 동시에 디스플레이하고 있는 현재 상태를 가질 수 있다. 발표자는 이어서, 예컨대 다른 청중 멤버로부터의 질문에 답하기 위해 슬라이드 #5로 전환한다. 한편, 클라이언트 A는 웹 회의로부터 연결 해제된다. 그러면 발표자는 슬라이드 #3으로 전환하고 그런 다음 다시 슬라이드 #1으로 돌아간다. 재연결 시, 클라이언트 A는 현재 상태를 원한다. 토큰 메커니즘에 기반하는 롱 폴링을 통해, 서버나 서버 상에 존재하는 관리 모듈은 발표자가 슬라이드 #1으로 다시 전환했기 때문에 클라이언트 A가 현재 상태를 가진다고 판단한다. 따라서 어떤 상태 업데이트들도 클라이언트 A로 보내지지 않는다. 한편, 이전의 서버 이벤트로 구동되는 폴링 기법들을 이용하여, 최종적으로 슬라이드 #1에서 서버와 동기하기 전에 클라이언트 A에게 먼저 슬라이드 #5 및 슬라이드 #3에 관한 업데이트가 보내질 것이다. 또한, 클라이언트 A가 다시 슬라이드 #1으로 돌아올 때쯤, 발표자는 예컨대 이미 슬라이드 #2로 전환하였을 수 있다. 서버 응답을 상태 업데이트로 국한시키기기 위한 토큰 메커니즘을 통한 롱 폴링은 예컨대, 데이터를 클라이언트 브라우저로 보다 빠르고 저렴하게 전송하는 것과 클라이언트와 서버 사이에서 보다 일관되고 동기된 데이터를 만든다는 것을 포함하는 수많은 이점들을 가져온다.

일 실시예에서, 웹 서버와 같은 서버는 문서 편집 세션을 포함하는 애플리케이션 등으로부터 상태 업데이트를 수신한다. 실시예들에서 그러한 업데이트는 서버에 상주하는 관리자나 관리 모듈에서 수신된다. 그러면 서버에서의 상태는 그 수신된 상태 업데이트를 반영하기 위해 변경된다. 그 상태가 해싱되어 상태의 해시 값을 포함하는 토큰을 생성한다. 실시예들에 따라, 서버가 어떤 상태 업데이트에 대한 클라이언트 요청, 예컨대 장기 유지 요청을 수신할 때, 서버는 요청한 클라이언트로부터 수신된 토큰과 서버 상의 토큰을 비교한다. 토큰들이 매치되면, 클라이언트는 서버와 동기된 것으로, 예컨대 클라이언트는 데이터의 현재 상태를 가진다. 그에 따라 서버는 클라이언트 요청 및 수신된 토큰을 계속 보유한다. 한편 상기 토큰들이 서로 다르면, 클라이언트는 서버와 동기가 맞지 않는 것이므로 데이터의 현재 상태를 갖지 않는 것이다. 따라서 서버는 서버 상의 현재 토큰과 함께 실제 상태를 클라이언트에 푸쉬한다. 실시예들에서 클라이언트는 그러면 자신의 데이터를 업데이트할 수 있다. 또 다른 실시예들에서, 클라이언트는 또한 상태 업데이트에 대한 후속 요청과 함께 전송할 수신된 토큰을 저장한다. 실시예들에 따라, 그로써 클라이언트 및 서버는 데이터 교환을 위한 지속적 연결을 유지하며, 클라이언트가 데이터에 대한 현재 상태를 가지지 않는다고 판단될 때 상태 데이터만이 클라이언트로 전송된다. 설명했듯이, 실시예들에서 클라이언트로부터의 요청은 롱 폴링 기법의 일부인 장기 유지 요청이다. 또 다른 실시예들에서 클라이언트에 의한 롱 폴링은 HTTP 롱 폴링을 포함한다. 다른 실시예들에서는 정기적 폴링이 사용된다.

토큰 메커니즘의 사용을 통해, 그에 따라 서버는 상태가 바뀌었는지를 판단하기 위해 전체 데이터 세트가 아닌 토큰들을 비교할 수 있다. 그에 따라 상태 데이터 자체가 아닌 토큰 값의 비교는 클라이언트 요청에 대한 서버 응답 시간을 크게 개선시킨다. 또한 서버가 상태의 차이가 일어난다고 판단하는 시점에 서버의 결과적인 현재 상태에 영향을 미치지 않았을 개재 이벤트들이 아닌 현재의 상태를 클라이언트에게 전송하기 때문에 불필요한 상태 업데이트가 회피된다. 따라서 실시예들은 서버 응답의 데이터가 서버 이벤트들이 아닌 상태 업데이트에 국한되게 제공한다. 결과적으로 클라이언트 및 서버 콘텐츠 사이의 일관성이 개선되며, 데이터는 보다 빠르게 시스템 자원들의 불필요한 소비를 줄이며 전송된다.

또한 롱 폴링을 통해, 클라이언트들은 이전의 상태 데이터 수신으로부터 상태가 변화했는지를 검사하는 빠른 방법을 가진다. 실시예들에서 클라이언트들은 실제 상태를 판단함에 있어 보다 많고/거나 보다 많은 복잡성을 제시할 가능성이 있는 상태 데이터 대신 토큰들이나 토큰 값들만을 비교할 수 있다.

추가 실시예들에 따르면, 클라이언트는 서버에게 자신의 장기 유지 폴링 요청 시 토큰 값으로 빈 값이나 무작위/디폴트 값을 전송함으로써 상태 업데이트에 대한 서버로부터의 즉각적 응답을 강요할 수 있다. 다른 실시예들에서 응답은 소정 시간 주기 내에, 또는 예컨대 시스템 자원들의 가용성으로 인해 서버가 응답할 수 있을 때 이뤄져야 한다. 빈 값 또는 무작위/디폴트 값은 서버가 서버 상의 토큰 및 수신된 토큰이 서로 다르다고 판단하게 한다. 결과적으로 서버는 자신의 상태 데이터 및 서버 상의 토큰을 클라이언트로 전송함으로써 즉시 응답한다. 그에 따라 클라이언트는 다음 보통 서버 푸쉬를 기다리지 않고 즉각적인 응답을 획득할 수 있다. 그에 따라 클라이언트는 클라이언트가 먼저 서버와 접속을 개시할 때나 클라이언트가 접속 해제되었을 때나 그렇지 않고 서버 콘텐츠 변화에 뒤쳐 있었을 때와 같은 때에 서버와 보다 빠르게 동기할 수 있다. 따라서 토큰으로 빈 값이나 무작위/디폴트 값을 보내는 것은 서버 종단이 롱 폴링에서 정기적 폴링으로 논리적으로 전환할 수 있게 한다.

또한, 일부 실시예들이 보이다시피, 토큰의 사용은 클라이언트들이 서버 응답의 타이밍에 의존하지 않게 한다. 그에 따라 서버는 롱 폴링을 이용하여 클라이언트로부터 수신된 토큰이 서버 상의 토큰과 매치하더라도 즉시 응답하는 옵션을 가진다. 그러한 융통성은 예컨대, 서버(들)이 개방형 접속을 원하지 않는 경우 셧다운되거나 어떤 다른 동작을 하는 경우에 유용한다.

도 1a를 참조하면, 본 개시의 실시예들에 따라 상태 업데이트에 대한 장기 유지 폴링 요청의 파라미터로서 토큰을 이용하는 예시적인 논리적 환경이나 시스템(100A)이 도시된다. 클라이언트 컴퓨터(102)가 서버(108)로 상태 업데이트(128) 요청을 전송한다. 일 실시예에서 서버(108)는 프론트엔드(front-end) 서버라 불린다. 실시예들에서 생략부호(110)와 서버(112)에 의해 도시된 것과 같은 임의 개수의 서버들이 사용될 수 있다. 클라이언트 컴퓨터(102)는 예컨대 사용자(104)에 의해 웹 페이지들의 보기를 위해 웹 브라우저와 같은 브라우저를 실행한다. 그러한 웹 페이지들이나 문서들이나 기타 데이터는 예컨대 클라이언트 컴퓨터(102) 상에서 실행되는 사용자 인터페이스 모듈을 통해 사용자 인터페이스로 디스플레이되거나 출력된다. 클라이언트 컴퓨터(102)에서 서버(108)로 보내지는 상태 업데이트(128)에 대한 요청은 네트워크(106)를 거쳐 전송된다. 상태 업데이트(128)에 대한 요청은 파라미터로서 토큰을 포함한다. 요청(128) 안의 토큰은 클라이언트에 의해 이해되는 서버에서의 상태에 대한 해시이다. 예를 들어 일 실시예에서, 클라이언트는 이전의 상태 업데이트 요청에 대한 서버에 의한 응답 안에 토큰을 수신했을 수 있다. 다른 실시예에서 요청(128) 안의 토큰 값은 빈 값 또는 무작위/디폴트 값이거나 어떤 타입의 "더미" 값을 포함할 수 있다. 그러한 빈 값 또는 무작위/디폴트 값 혹은 더미 값은 일 실시예에 따라, 클라이언트가 먼저 서버와 접촉을 개시하고 있을 때와 같이 클라이언트가 그 값을 알지 못할 때 포함될 수 있다. 다른 실시예에서, 빈 값 또는 무작위 디폴트 값 또는 더미 값은 클라이언트에 의해 (올바른 토큰 값을 무시하면서) 서버가 클라이언트의 상태 업데이트 요청에 즉시 응답하게 하기 위해 의도적으로 사용된다. 다른 실시예에서 서버 응답은 서버가 응답할 할 수 있게 되자마자 발생한다. 또 다른 실시예에서 서버 응답은 서버에 의해 설정된 소정 시간 주기 안에 발생한다. 또 다른 실시예에서 서버 응답은 클라이언트에 의해 설정된 소정 시간 주기 안에 발생한다. 요청(128)은 도 1a에서 HTTP 요청인 "GetState"를 포함하는 것으로 도시되지만, 본 개시의 실시예들에 따른 어떤 유형의 요청이라도 본 개시의 사상과 범위에서 벗어나지 않은 채 사용될 수 있다.

토큰(128)과 함께 상태 업데이트 요청을 수신함에 대응해서, 서버(108)는 서버 상의 현재 토큰이 수신된 토큰과 매치하는지 여부를 판단한다. 상기 토큰들이 매치하지 않으면, 서버(108)는 서버 상의 토큰 값을 상태 데이터(130)와 함께 클라이언트(102)로 전송함으로써 응답한다.

도 1a는 클라이언트 컴퓨터(102) 및 서버(108) 사이의 메시지 교환을 도시하지만, 도 1b는 본 개시의 또 다른 실시예들에 따라 서버(108)가 백엔드(back-end) 서버(116)와 통신하는 프론트엔드 서버인 추가적인 옵션 환경(100B)을 또한 보여준다. 도 1a 및 1b는 본 개시의 기능이 구현될 수 있는 예시적인 논리적 환경들을 도시한다. 논리적 환경들(100A 및 100B)은 어떤 특정한 구현예에 한정되지 않으며, 대신 여기 기술된 환경의 기능이 실시될 수 있는 어떠한 컴퓨팅 환경이라도 구현할 수 있다. 도 1a 및 1b는 예시할 목적으로 제공된다.

도 1b를 참조하면, 백엔드 서버(116)가 도시되지만, 여기 개시된 실시예들에 따라 생략부호(118)와 백엔드 서버(120)로 도시된 바와 같이 복수의 백엔드 서버들이 사용될 수 있다. 일부 실시예들은 도 1a에 도시된 것과 같이 백엔드 서버(들) 없이 클라이언트 컴퓨터(102)와 서버(108)를 이용하여 발생하는 토큰 메커니즘을 통해 롱 폴링을 제공하기 때문에, 백엔드 환경의 구성요소들은 선택적 구성요소들로서 점선들로 도시된다. 도 1b에 도시된 백엔드 서버들(116-120)을 포함하는 가능한 실시예에서, 서버(108)는 프론트엔드 서버로 지칭되며 여기서 프론트엔드 서버(108)(또는 110, 112)는 클라이언트(102)로부터 백엔드 서버(116)로 최초에 수신되는 상태 업데이트 요청(132)을 전송한다. 도시된 바와 같이, 본 개시의 실시예들에 따른 여러 개의 백엔드 서버들이 생략부호(118)와 백엔드 서버(120)로 도시된 바와 같이 사용될 수 있다. 상태 업데이트 요청(132)은 요청의 파라미터로서 토큰을 포함한다. 요청(132)은 도 1b에서 HTTP 요청인 "GetState"를 포함하는 것으로 도시되지만, 본 개시의 실시예들에 따른 임의 유형의 요청이라도 본 개시의 사상과 범위에서 벗어나지 않으면서 사용될 수 있다.

실시예들에서 클라이언트로부터 토큰과 함께 상태 업데이트 요청(132)을 수신함에 대응해서 백엔드 서버(116)는 서버 상의 토큰을 수신된 토큰과 비교한다. 일 실시예에서 서버(116(또는 서버들(118, 120)) 상에서 실행되는 관리자(또는 관리) 모듈이나 구성요소(122)는 서버 상의 토큰을 클라이언트로부터 수신된 토큰과 비교한다. 도 1b는 모듈(122)을 "관리자" 모듈이나 구성요소로 부르지만, 이 모듈이나 구성요소는 본 개시의 사상과 범위로부터 벗어나지 않으면서 어떤 이름으로나 불릴 수 있다. 또한 관리 모듈(122)은 실시예들에 따른 소프트웨어를 포함할 수 있지만, 다른 실시예들은 여기에 기술되는 방법들을 실행할 컴퓨터 프로그래밍 코드를 위한 하드웨어가 되도록 제공한다.

일 실시예에서 서버(116) 및/또는 관리자 모듈(122)은 서버에서의 상태를 해싱함으로써 서버 상의 토큰에 대한 값을 계산한다. 실시예들에 따르면 예컨대 문서 편집 세션(126)을 포함하는 애플리케이션으로부터 네트워크(124)를 거쳐 상태 업데이트(134)가 수신된다. 다른 실시예들에서 상태 업데이트는 다른 서버, 클라이언트 컴퓨터, 컴퓨터 시스템, 다른 컴퓨팅 시스템에서 실행되는 작업 플로우, 및/또는 웹 브라우저 등으로부터 수신된다. 문서 편집 세션(126)은 본 개시에 대한 가르침을 예시하기 위한 예를 들 목적으로만 제공된다. 토큰 값은 본 개시의 실시예들에 따라 데이터베이스(138) 안에 저장될 수 있고, 아니면 다른 실시예들에서 토큰 값은 예컨대 서버(116)(또는 118, 120)에 부착된 데이터베이스(들)에 저장될 수 있다.

서버(116) 및/또는 관리자 모듈(122)은 클라이언트(132)로부터 수신된 토큰이 서버(116) 상의 토큰과 상이한지를 판단한다. 그 값들이 상이하면, 서버(116)는 서버(136) 상의 토큰과 함께 데이터를 네트워크(114)를 거쳐 프론트엔드 서버(108)로 전송함으로써 클라이언트 요청에 응답한다. 데이터 및 토큰을 수신함에 대응해서, 프론트엔드 서버(108)는 일 실시예에 따라 이제 상태 데이터 및 토큰(130)을 네트워크(106)를 거쳐 클라이언트(102)로 전송한다. 다른 실시예에서, 프론트엔드 서버(108)는 그들을 수신할 때 데이터와 토큰을 보내지 않고 대신 일정 시간 대기한다. 그러한 일정 시간은 실시예들에 따라 미리 정해지거나 다른 실시예들에서 가용 시스템 자원들에 따라 좌우된다.

일 실시예에서 서버(116)(및/또는 서버(108))로부터 보내진 데이터(136)(또는 130)는 상태 업데이트(들)을 반영한 상태 데이터를 포함한다. 다른 실시예들에서 서버(116)(및/또는 서버(108))로부터의 데이터(136)(또는 130)는 상태 업데이트들 외에 데이터를 포함한다. 실시예들은 요청들(128 및 132) 안의 토큰들이 상태 업데이트 요청들에 대한 파라미터들로서 포함되도록 제공하지만, 또 다른 실시예들에서 요청들(128 및 132)과 관련하여 보내진 토큰들은 요청들과 따로 전송된다. 또한, 실시예들은 서버 상의 토큰이 응답(136 및 130) 안에서 상태 데이터와 함께 전송되도록 허용하지만, 다른 실시예들은 서버 상의 토큰이 데이터와 따로 전송되도록 허용한다.

논리적 환경들(100A 및 100B)은 어떤 특정한 구현예에 한정되지 않으며, 대신 여기 기술된 환경의 기능이 실시될 수 있는 어떠한 컴퓨팅 환경이라도 구현할 수 있다. 예를 들어 실시예들에 따라 당업자에 의해 이해되는 어떤 유형의 클라이언트 컴퓨터(102)라도 사용될 수 있다. 또한 네트워크들(106, 114 및 124)은 개별적인 단일 네트워크들로서 도시되지만 당업자에 의해 일반적으로 이해되는 어떤 유형의 네트워크들이라도 될 수 있다. 일 실시예에 따르면, 네트워크는 글로벌 네트워크(가령, 인터넷이나 월드 와이드 웹, 즉 줄여서 "Web")일 수 있다. 그것은 LAN(local area network), 예컨대 인트라넷이나 WAN(wide area network)일 수도 있다. 실시예들에 따르면, 네트워크들(106, 114 및 124)을 통한 통신은 하나 이상의 표준 패킷 기반 포맷들, 가령 H.323, IP, 이더넷 및/또는 ATM에 따라 발생한다.

또한, 본 개시의 실시예들에 따라 당업자에 의해 이해되는 어떤 인지 가능한 환경이나 시스템이라도 사용될 수 있다. 도 1a 및 1b는 여기 개시된 실시예들의 가르침을 이해하기 위한 목적의 예들로서만 제공된다. 예를 들어 도 1b는 서버들(108-122 및 116-120)을 보인다. 그러나 실시예들은 어떤 유형의 서버, 별도 서버들, 서버 팜(farm), 서버 클러스터 또는 다른 메시지 서버 역시 포괄한다. 또한, 도 1a 및 1b는 클라이언트 컴퓨터(102)를 도시한다. 그러나, 여기 개시된 실시예들의 사상 및 범위로부터 벗어나지 않으면서 당업자에 의해 이해되는 모든 유형의 소형 컴퓨터 장치가 사용될 수 있다. 오직 하나의 클라이언트 컴퓨터(102) 만이 도시되고 있지만, 예컨대 다른 실시예는 여러 소형 컴퓨터 장치들이 서버들(108-112 및 116-120)과 통신하도록 제공한다. 일 실시예에서 각각의 소형 컴퓨터 장치는 네트워크(106)고 통신하거나, 다른 실시예들에서 여러 개의 개별 네트워크들이 소형 컴퓨터 장치들과 통신한다. 또 다른 실시예에서 각각의 소형 컴퓨터 장치는 별도의 네트워크와 통신한다. 실제로 환경들이나 시스템들(100A 및 100B)은 여기에 개시된 실시예들을 실시하는 유효한 방식들을 나타내지만 어떤 식으로든 본 개시의 범위를 한정하도록 의도되지 않는다. 또한 예시적 네트워크 환경들(100A 및 100B)은 기술된 특정 구성요소들, 예컨대 서버, 클라이언트 컴퓨터 등과 관련하여 고려될 수 있고, 혹은 다른 대안으로서 그러한 장치들에 해당하는 유사 모듈들과 관련하여 고려될 수 있다.

도 1b는 클라이언트 컴퓨터(102) 및 서버들(108-112 및 116-120)을 도시하고, 도 2a는 본 개시의 실시예들에 따라 상태 업데이트에 대한 장기 유지 폴링 요청의 파라미터로서 토큰을 이용하는 소프트웨어 모듈들이나 구성요소들의 논리적 표현(200A)을 도시한다. 클라이언트 컴퓨터(202A)는 상태 업데이트를 위해 서버(204A)를 폴링하기 위한 웹 브라우저 모듈(206)을 포함한다. 다른 실시예들에서 클라이언트 컴퓨터(202A)는 웹 브라우저 모듈(206)의 사용 없이 서버(204A)를 폴링한다. 추가 실시예들은 서버(204A)로부터 수신된 웹 페이지들, 문서들, 데이터 등을 보기 위한 사용자 인터페이스를 디스플레이하기 위해 클라이언트 컴퓨터(202A) 상에서 실행될 사용자 인터페이스 모듈(207)을 포함하는 추가 모듈들을 포함하도록 클라이언트 컴퓨터(202A)를 제공한다. 클라이언트 컴퓨터(202A)는 여기 개시된 실시예들에 따라 토큰 메커니즘을 통해 롱 폴링을 제공하기 위해 생략부호(208)로 도시된 바와 같이 다른 모듈들이나 구성요소들(210)을 포함한다.

토큰 메커니즘을 통한 상태 업데이트의 롱 폴링 요청을 수신함에 대응해서, 서버(204A)는 수신된 요청 및 토큰을 분석한다. 일 실시예에서, 예컨대 서버(204A)는 서버(204A) 상에서 실행되는 관리 모듈(212)을 포함한다. 관리 모듈(212)은 예컨대 도 1b의 관리자 모듈이나 구성요소(122)에 해당하며, 본 개시의 사상과 범위에서 벗어나지 않으면서 임의의 이름으로 지칭될 수 있다. 관리 모듈이나 구성요소(212)는 가령 문서 편집 세션을 포함하는 애플리케이션 등으로부터 상태 업데이트를 수신한다. 관리 모듈(212)은 상태 업데이트를 반영하기 위해 서버(204A)의 상태를 변경하고 그 상태를 해싱한다. 해싱된 상태 값은 서버의 상태를 반영한 서버 상의 토큰을 생성하는 데 사용된다. 예시적 실시예들에 따르면 관리 모듈(212)은 클라이언트의 상태 데이터가 현재인지를 판단하기 위해 클라이언트(202A)로부터 수신된 토큰(들)과 비교하는 데 서버 상의 토큰을 이용한다. 실시예들에서 관리 모듈(212)은 그에 따라 가령 클라이언트로부터 수신된 토큰 값을 평가함으로써 상태 업데이트에 대한 클라이언트 요청에 대한 응답을 제공한다. 본 개시의 실시예들에 따르면 서버(204A)는 토큰 메커니즘을 통해 상태 업데이트에 대한 장기 유지 요청들에 응답하기 위해 생략부호(214)로 도시된 것과 같은 다른 모듈들이나 구성요소들(216)을 포함한다.

도 2b를 참조하면, 본 개시의 실시예들에 따라 클라이언트(202B)로부터 서버(204B)로 상태 업데이트를 요청하는 환경이나 시스템(200B)의 논리적 표현이 도시된다. 가령 도 2a의 클라이언트(202A)에 상응하는 것과 같은 클라이언트(202B)가 요청(218)의 파라미터로서 토큰과 함께 요청을(218)을 서버(204B)로 전송한다. 서버(204B)는 예컨대 도 2a의 서버(204A)에 상응한다. 요청(218)은 도 1a 및 1b에서 HTTP 요청인 "GetState"를 포함하는 것으로 도시되지만, 본 개시의 실시예들에 따른 어떤 유형의 요청이라도 본 개시의 사상과 범위에서 벗어나지 않으면서 사용될 수 있다. 그에 대응하여 서버(204B)는 실시예들에 따라 상태 데이터 및 서버 상의 토큰을 포함하는 응답 메시지(220)를 클라이언트(202B)로 전송한다. 도 2b는 하나의 요청(218)과 하나의 응답(220)을 도시하지만, 다른 실시예들은 여러 요청들과 응답 메시지들을 제공한다. 또한, 실시예들은 토큰 메커니즘을 통한 롱 폴링 기법의 일부로서 장기 유지 요청이 되도록 요청(218)을 제공하지만, 다른 실시예들은 토큰 메커니즘을 통한 정기적 폴링 기법을 제공한다. 또 다른 실시예에서, 요청 메시지(218)는 어떤 유형의 폴링 기법도 수반하지 않고 클라이언트(202B)로부터 서버(204B)로 전송된다. 도 2a 및 2b는 예시적 구성요소들 및/또는 모듈들을 도시하지만, 이러한 구성요소들 및/또는 모듈들은 본 개시의 가르침을 예시하기 위한 예로 들 목적으로만 제공된다. 실시예들에서 모듈들 및/또는 구성요소들이 결합될 수 있다. 또한 본 개시의 사상 및 범위로부터 벗어나지 않으면서 추가적이거나 더 적은 모듈들 및/또는 구성요소들이 사용될 수 있다.

도 3은 다음으로 본 개시의 실시예들에 따라 상태 업데이트를 클라이언트 및/또는 브라우저로 푸쉬할지 여부를 결정하는 예시적 동작 단계들(300)을 도시한다. 도 3에 예시된 예시적 동작 단계들(300)은 일 실시예에 따라 서버 및/또는 관리 구성요소 측면에서 보여진다. 프로세스(300)는 시작 동작(302)에서 개시되어 상태 업데이트를 수신(304)하도록 진행하며, 이때 서버 및/또는 서버 상에서 실행되는 관리 구성요소는 예컨대 문서 편집 세션으로부터 문서 및/또는 웹 페이지에 대한 변경과 같은 상태 업데이트(304)를 수신한다. 예를 들어 웹 페이지에 대한 편집이 애플리케이션 프로그램의 공동 저작 세션에서 일어날 수 있다. 서버는 다음으로, 수신된 상태 업데이트(들)에 기반하여 서버(306)의 상태를 변경한다. 일 실시예에서, 서버는 먼저, 수신된 상태 업데이트가 서버에서의 실제적 상태 데이터 변경을 나타내는지를 판단한다. 실시예들에 따르면, 실제적 상태 데이터 변경이 수신된 상태 업데이트로부터 비롯되는 경우 서버의 상태 데이터가 변경된다(306). 프로세스(300)는 이어서, 토큰에 대한 값을 생성(310)하기 위해 상태가 해싱되는 해시 상태 동작(308)으로 진행한다. 실시예들에서 이 토큰은 저장된다. 조회(312)는 어떤 토큰들이 보유되는지 여부를 판단한다. 예를 들어 롱 폴링을 이용하여 장기 유지 요청들을 수반하는 실시예들에서, 예컨대 서버는 서버에서 현재 보유된 상태 업데이트에 대한 요청 안에 클라이언트 컴퓨터 및/또는 브라우저로부터의 토큰을 수신했을 수 있다. 토큰이 보유된 경우, 프로세스(300)는 예로서 조회(314)로 진행하여 보유된 클라이언트 토큰이 서버 상의 토큰과 매치하는지 여부를 판단한다. 토큰들이 매치하지 않으면, 프로세스(300)는 아니오로 진행하여 토큰과 함께 데이터를 전송하며, 이때 상태 데이터 및 서버 상의 토큰 값이 클라이언트로 전송된다(316). 그런 다음 프로세스(300)는 종료 동작(318)에서 종료된다.

다시 조회(312)로 돌아가서, 아무 토큰들도 보유되어 있지 않으면, 프로세스(300)는 아니오로 진행하여 클라이언트 등으로부터 상태 업데이트에 대한 요청과 함께 토큰이 수신되는지를 판단한다. 토큰이 수신되지 않으면, 프로세스(300)는 아니오로 진행하여 상태 업데이트를 수신하며(304), 이때 서버는 상태(304)의 추가적 변화를 수신할 수 있다. 그런 다음 조회(312)까지 단계들(304)이 반복된다. 조회(322)에서 토큰이 클라이언트로부터 수신되면, 프로세스(300)는 예스로서 조회(314)로 진행하여 서버 상의 토큰이 클라이언트로부터 수신된 토큰과 다른지 여부가 판단된다. 토큰들이 매치하면 프로세스(300)는 예스로서 단계 320으로 진행하여 클라이언트 요청, 예컨대 수신된 토큰과 함께 장기 유지 요청을 유지한다. 프로세스(300)는 그런 다음 상태 업데이트를 수신하도록(304) 진행하며 그런 다음 단계들(304-312)이 반복된다. 토큰들이 매치하지 않으면, 프로세스(300)는 아니오로 진행하여 클라이언트로 서버 상의 토큰 값과 함께 데이터를 전송한다(316). 그런 다음 프로세스(300)는 종료 동작(318)에서 종료된다.

도 3은 상태 업데이트를 푸쉬할지 여부를 판단하기 위한 프로세스의 예시적 동작 단계들을 예시하지만, 도 4는 본 개시의 일 실시예에 따라 상태가 변경되었는지를 판단하기 위해 토큰들을 비교하는 예시적 동작 단계들을 도시한다. 도 4에 예시된 예시적 동작 단계들(400)은 일 실시예에 따라 클라이언트 및/또는 브라우저 측면에서 보여진다. 프로세스(400)는 시작 동작(402)에서 개시되어 클라이언트(및/또는 브라우저)가 서버에서의 현재 상태를 원하는지 여부가 판단되는 상태 조회(404)를 바라도록 진행한다. 예를 들어 클라이언트는 일 실시예에 따라, 서버와 동기되는지를 알고 싶어할 수 있다. 서버에서의 상태가 요망되지 않으면, 프로세스(400)는 아니오로 진행하여 프로세스(400)가 종료되는 종료 단계(420)로 진행한다. 그러나 서버에서의 상태가 요망되면, 프로세스(400)는 예로 진행하여 제1토큰/해시 파라미터와 함께 상태를 요청하며, 여기서 클라이언트는 서버에게 현재 상태에 대한 요청을 보낸다. 일 실시예에서, 이 요청은 서버로부터 상태 업데이트를 획득하기 위한 롱 폴링 기법의 일부로서의 장기 유지 요청이다. 제1토큰 또는 클라이언트 토큰이 본 개시의 실시예들에 따라 요청(406)의 파라미터로서 이 요청과 함께 전송된다. 예를 들어 클라이언트는 이전에 서버로부터 토큰 값을 수신했을 수 있으며, 이때 클라이언트는 일 실시예에서 이 토큰 값을 요청 파라미터로서 서버에 전송한다. 다른 실시예에서 클라이언트는 토큰 값을 빈 값이나 무작위/디폴트 값 또는 더미 값으로 세팅한다. 또 다른 실시예에서 토큰은 클라이언트 요청과 별개로 전송된다.

상태 업데이트에 대한 요청에 대응하여, 클라이언트는 제2토큰(408)과 함께 상태 데이터를 수신한다. 일 실시예에서 제2토큰은 서버 상의 토큰의 값이며, 여기서 서버 상의 토큰 값은 서버에서의 현재 상태의 해시를 나타낸다. 실시예들은 서버 상의 토큰이 클라이언트에 대한 (상태 데이터를 포함하는) 응답의 파라미터로서 전송되도록 제공한다. 다른 실시예들에서 토큰은 상태 데이터와 별개로 전송된다. 이어서 클라이언트는 자신이 서버에서 어떤 상태 변화가 있었는지를 판단하기 위해 토큰들을 비교하고 싶어하는지를 판단한다(410). 실시예들에서 토큰들의 비교는 클라이언트들이 이전 상태 업데이트로부터 상태가 변화되었는지를 검사하는 빠른 방식을 제공한다. 클라이언트들은 예컨대 더 크거나/더 많은 복잡한 상태 데이터 대신 토큰들을 비교할 수 있다. 클라이언트가 토큰들을 비교하고자 하는 경우, 프로세스(400)는 예로서 토큰들이 다른지 여부를 판단(412)하는 조회(412)로 진행한다. 토큰들이 서로 다르지 않으면, 예컨대 이들이 매치하면, 프로세스(400)는 아니오로서 클라이언트가 상태 업데이트를 요청하고 싶어하는지를 판단하기 위한 조회(404)로 진행하며, 프로세스(400)는 그런 다음 실시예들에 따라 단계들(404-410)을 반복하거나 종료 동작(420)에서 종료된다. 한편, 실시예들에 따라, 토큰들이 서로 다르면 프로세스(400)는 예로 진행하여 상태를 업데이트하며(416), 이때 클라이언트는 상태 데이터를 업데이트하고(416) 단계(408)에서 서버로부터 수신된 제2토큰 또는 토큰 값을 저장한다(418).

조회(410)로 돌아가서, 클라이언트가 상태 변화가 있었는지를 판단하기 위해 토큰들을 비교하고 싶어하지 않는 경우, 프로세스(400)는 아니오로서 클라이언트에서의 상태 데이터가 단계 408에서 서버로부터 수신된 상태 데이터와 상이한지를 판단하는 조회(414)로 진행한다. 실시예들에서 상태 데이터가 상이한지 여부를 판단하는 것은 예컨대 조회(412)에서 토큰들이 상이한지를 판단하는 것보다 훨씬 더 복잡하다. 상태 데이터가 상이한 경우, 프로세스(400)는 예로 진행하여 상태 동작을 업데이트하고(416) 제2토큰을 저장하며(418), 이때 클라이언트는 서버로부터 수신되어 후속 요청과 함께 전송될 토큰이나 토큰 값을 저장한다. 실시예들에서 클라이언트는 제2토큰을 맹목적으로 저장하고 애플리케이션이 요구함에 따라 수신된 상태 데이터를 이용한다. 제2토큰을 저장함으로써 클라이언트는 후속 요청 안에 파라미터로서 제2토큰을 포함시켜 상태 업데이트에 대한 서버로의 후속 요청 안에 자신의 현재 상태를 지시할 수 있다. 조회(414)에서 상태 데이터가 다르지 않으면, 실시예들에 따라 프로세스(400)는 아니오로 진행하여 상태 조회(404)를 원하여 단계들(404-410)이 반복되거나, 프로세스(400)가 종료 동작(420)에서 종료된다.

도 5를 참조하면, 본 개시의 실시예들에 따라 상태 업데이트 요청에 대한 응답을 강제하기 위한 예시적 동작 단계들이 도시된다. 도 5에 예시된 예시적 동작 단계들(500)은 일 실시예에 따라 클라이언트 및/또는 브라우저, 예컨대 웹 브라우저 측면에서 보여진다. 프로세스(500)는 시작 동작(502)에서 개시되고, 프로세스(500)는 클라이언트(및/또는 가령 브라우저)가 서버 응답을 강제하는 것을 요망하는지를 판단하기 위한 조회(504)로 진행한다. 실시예들에서 클라이언트가 서버로부터 응답을 강제하도록 요망할 수 있으며, 이때 클라이언트는 가령 클라이언트에서의 서비스 중단 후 서버와 동기가 어긋난다는 것을 인지한다. 다른 실시예들에서 클라이언트는 서버 응답을 반복적으로 강제함으로써 달성되는 것과 같은 정기적 폴링으로 전환하기를 요망하며, 이때 클라이언트는 예컨대 스마트폰과 같은 휴대형 컴퓨팅 장치 상에 있으며 가령 폴링을 가능하게 하는 전원에 플러깅하는데, 이때 폴링은 통상적으로 계산적으로 더 많이 요구하고 더 많은 전력을 소비한다. 아니면 다른 예로서, 클라이언트가 네트워크가 다운되거나 보다 잦은 서비스 중단을 경험하는 경우 폴링이 더 안전하다고 판단할 수 있고 주기적으로 폴링하고자 요망할 수 있다. 또한 클라이언트는 서버 부하나 접속 처리 문제로부터 일어나는 에러들을 보다 안정적으로 다루기 위해 롱 폴링에서 보통 또는 정기 폴링으로 전환하고자 할 수 있다. 또한 클라이언트는 롱 폴링이 클라이언트가 일하고 있는 환경, 예컨대 사용자가 편집자 뿐인 멀티 유저 편집 환경에서 단순히 필요하지 않기 때문에, 가령 서버 응답을 강제함으로써 폴링으로 전환하고자 할 수 있다.

서버 응답이 강제되는 경우, 실시예들에 따라 그 응답은 즉시 전송될 수 있다. 다른 실시예들에서 서버는 소정 시간 주기에 따라 응답한다. 또 다른 실시예들에서 서버는 예컨대 가용 시스템 자원들에 의해 결정되는 시간 주기 안에서 응답한다. 본 개시의 범위 및 사상을 벗어나지 않으면서 본 개시의 실시예들에 따라 서버에 의한 응답을 위해 수많은 시간 주기들이 적용될 수 있다.

도 5로 돌아가서, 클라이언트가 서버 응답(504)을 강제하고자 요망하는 경우, 프로세스(500)는 예로 진행하여 빈 토큰 값과 함께 상태를 요청하며(506), 이때 클라이언트는 상태 업데이트 요청 안에 토큰 값으로서 빈 값을 전달한다. 다른 실시예에서 클라이언트는 상태 응답을 강제하기 위해 토큰 값으로서 더미 값을 전달한다. 그에 따라 그러한 실시예들에서 클라이언트는 빈 값이나 무작위/디폴트 값 또는 더미 값을 전송 시 올바른 토큰 값을 무시한다. 아니면 다른 실시예들에서 클라이언트는 가령 서버와의 연결을 개시할 때 올바른 토큰 값을 알지 못한다. 서버가 토큰 값으로 빈 값이나 무작위/디폴트 값 또는 더미 값을 수신하기 때문에, 서버 상의 토큰은 클라이언트로부터 수신된 토큰과 매치하지 않으며 그에 따라 클라이언트는 실제 상태 및 서버 상의 토큰 값을 수신한다(508). 서버 상의 토큰 값은 본 개시의 사상 및 범위로부터 벗어나지 않으면서 서버 상의 토큰, 제2토큰 등으로 불릴 수 있다. 프로세스(500)는 이어서 토큰들이 다른지를 판단하기 위한 조회(510)로 진행하며, 이때 클라이언트에서의 토큰 값, 가령 제1토큰이 서버 상의 토큰, 가령 제2토큰과 상이한지 여부가 판단된다. 토큰들이 상이하면, 클라이언트가 앞서 자신의 상태를 업데이트한 이후 서버에서의 상태가 바뀐 것이다. 실시예들에서, 그에 따라 클라이언트는 서버와 동기가 어긋나 있다. 토큰들이 상이하다고 판단된 경우, 프로세스(500)는 예로 진행하여 상태를 업데이트하고(512) 제2토큰을 저장한다(514). 서버로부터 수신된 상태 데이터는 그에 따라, 단계 512에서 클라이언트에서의 상태를 업데이트하는 데 사용되며, 서버로부터의 토큰은 서버에서의 상태 업데이트에 대한 가능한 후속 요청 시 사용되도록 저장된다(514). 그런 다음 프로세스(500)는 종료 동작(516)에서 종료된다.

조회(504)로 돌아가서, 클라이언트가 서버에 응답을 강요하고 싶어하지 않는 경우, 프로세스(500)는 아니오로 진행하여 제1토큰 값 요청 파라미터와 함께 상태를 요청하며(518), 이때 클라이언트는 토큰 값으로서 빈 값이나 무작위/디폴트 값 또는 더미 값을 사용하지 않고 대신 올바른 토큰/해시 값을 사용한다. 올바른 토큰/해시 값의 사용 결과로서, 서버로부터의 즉각적인 응답은 강제되지 않는다. 대신 클라이언트는 실시예들에서, 서버에서 상태 변화가 일어날 때까지 기다린다(520). 서버에서 상태 변화 또는 업데이트가 일어난 후, 클라이언트는 그 상태나 상태 데이터 및 제2토큰 또는 토큰 값을 서버로부터 수신한다(단계 508). 그런 다음 단계 510-514가 반복되며, 프로세스(500)는 종료 동작(516)에서 종료된다.

도 6은 이어서 본 개시의 실시예에 따라 데이터를 푸쉬하기 위해 토큰 값으로서 빈 값 또는 무작위/디폴트 값을 수신하는 예시적 동작 단계들을 예시한다. 도 6에 예시된 예시적 동작 단계들(600)은 일 실시예에 따라 서버 및/또는 관리 구성요소나 모듈 측면에서 보여진다. 프로세스(600)는 시작 동작(602)에서 개시되어, 해시 값의 토큰을 생성하기 위해(606) 서버에서의 상태 데이터가 해싱되는 해시 상태 동작(604)으로 진행한다. 이어서 서버(및/또는 관리 모듈이나 구성요소)는 토큰 값으로 빈 값 또는 무작위/디폴트 값과 함께 상태 업데이트들에 대한 요청을 수신한다(608). 실시예들에서 그러한 요청은 롱 폴링 기법의 일부인 장기 유지 요청이다. 실시예들에서 롱 폴링 기법은 HTTP 롱 폴링을 포함한다. 이어서 서버는 수신된 토큰이나 토큰 값을 단계 606에서 생성된 토큰과 비교한다. 빈 값 또는 무작위/디폴트 토큰 값 또는 더미 값이 요청 파라미터로서 포함되었기 때문에, 서버 상의 토큰과 수신된 토큰은 매치하지 않으며 그에 따라 서버는 단계 606에서 생성된 서버 상의 토큰과 함께 상태 데이터를 전송 또는 푸쉬한다(612). 그런 다음 프로세스(600)는 종료 동작(614)에서 종료된다.

도 3-6이 예시적 동작 단계들을 도시하였으나, 도시된 동작 단계들은 다른 단계들로 결합되고/거나 재배치될 수 있다. 또한 예컨대 더 적거나 추가되는 단계들이 사용될 수 있다.

마지막으로 도 7은 여기에 개시된 실시예들이 구현될 수 있는 예시적 컴퓨팅 시스템(700)을 도시한다. 적어도 하나의 프로세서(702)를 가지는 클라이언트 컴퓨터(102), 프론트엔드 서버들(108-112) 및 백엔드 서버들(116-120)과 같은 컴퓨터 시스템(700)이 여기 개시된 실시예들에 따라 도시된다. 시스템(700)은 예컨대 시스템 메모리, 휘발성 메모리 및 비휘발성 메모리를 구비하는 메모리(704)를 가진다. 가장 기본적인 구성 안에서 컴퓨팅 시스템(700)이 점선(706)으로 도 7에 예시된다. 또한 시스템(700)은 비한정적인 것으로서 자기 또는 광 디스크나 테이프를 포함하는 추가 저장부(착탈가능형 및/또는 비착탈가능형)을 포함할 수도 있다. 그러한 추가 저장부는 도 7에서 착탈형 저장부(708) 및 비착탈형 저장부(710)로써 예시된다.

여기서 사용된 컴퓨터 판독 가능 매체라는 용어는 컴퓨터 저장 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈이나 기타 데이터 같은 정보의 저장을 위해 어떤 방법 또는 기술로 구현된 휘발성 및 비휘발성, 착탈형 및 비착탈형 매체를 포함한다. 시스템 메모리(704), 착탈형 저장부(708) 및 비착탈형 저장부(710)는 모두 컴퓨터 저장 매체의 예들(즉, 메모리 저장부)이다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM(electrically erasable read-only memory), 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학적 저장부, 마그네틱 카세트, 마그네틱 테이프, 마그네틱 디스크 저장부 또는 다른 마그네틱 저장기, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터 장치(700)에 의해 액세스될 수 있는 어떤 다른 매체를 포함하나, 그에 국한되지 않는다. 그러한 어떤 컴퓨터 저장 매체는 장치(700)의 일부일 수 있다. 도 7의 예시도는 어떤 식으로든 본 개시의 범위를 한정하고자 의도되지 않는다.

본 명세서에서 사용된 바와 같은 컴퓨터 판독 가능 매체라는 용어는 통신 매체를 또한 포함할 수 있다. 통신 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 반송파나 다른 전송 메커니즘 같은 변조된 데이터 신호 속의 다른 데이터를 통해 구현될 수 있으며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 안에 정보를 인코딩하기 위한 방식으로 세팅되거나 변경되는 신호의 특성들 중 한 개 이상을 가지는 신호를 설명할 수 있다. 한정이 아닌 예로서, 통신 매체는 유선 네트워크나 직접 유선 연결 같은 유선 매체, 및 청각, RF(radio frequency), 적외선 및 다른 무선 매체 같은 무선 매체를 포함할 수 있다.

시스템(700)은 또한 장치가 다른 장치들과 통신할 수 있게 하는 통신 연결(들)(716)을 포함할 수 있다. 또한 본 개시의 일 실시예에 따라 예컨대 클라이언트 컴퓨터(102) 상의 해당 UI 모듈(미도시)에 의해 제공되는 바와 같은 예컨대 클라이언트 컴퓨터(102) 상의 사용자 인터페이스(UI)의 필드들 안에 콘텐츠를 입력하기 위해, 시스템(700)은 키보드, 마우스, 펜, 음성 입력 장치, 터치 입력 장치 등과 같은 입력 장치(들)(714)을 가질 수 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 기기(들)(712) 역시 포함될 수 있다. 이 기기들 모두는 이 기술 분야에 잘 알려져 있으므로 여기에 상세히 논의될 필요가 없다. 상술한 장치들은 예들로서 다른 것들이 사용될 수도 있다.

상기 도면들을 참조하여 본 개시의 실시예들을 기술하였으나, 당업자에게 용이하게 제시할 수 있고 본 개시의 범위와 사상 안에 포함되며, 첨부된 청구범위에 정의된 바와 같은 실시예들에 대한 수많은 변경이 이루어질 수 있다는 것을 알아야 한다. 실제로 실시예들은 본 개시의 목적을 위해 기술되었지만, 본 개시의 범위 안에서 다양한 변경 및 수정이 이루어질 수 있다.

마찬가지로, 본 개시가 구조적 특징들, 방법론적 행위들 및 그러한 행위들을 포함하는 컴퓨터 판독 가능 매체에 특정한 언어를 사용하였으나, 첨부된 청구범위에 정의된 발명의 대상이 여기에 기술된 특정한 구조, 행위들, 특징들 또는 매체에 반드시 국한되는 것은 아니라는 것을 알아야 한다. 그보다, 상술한 특정한 구조들, 특징들, 행위들 및/또는 매체는 청구범위를 구현하는 예시적 형태들로서 개시된다. 실시예들의 양태들은 여러 클라이언트 컴퓨터들, 여러 프론트엔드 서버들, 여러 백엔드 서버들 및 여러 네트워크들 등을 감안한다. 또는, 다른 실시예들에서, 하나의 프론트엔드 서버, 하나의 백엔드 서버 및 하나의 네트워크를 가진 하나의 클라이언트 컴퓨터가 사용된다. 또 다른 실시예들은 예컨대 하나의 프론트엔드 서버가 있고 백엔드 서버가 없는 하나의 클라이언트 컴퓨터를 허용한다. 당업자는 본 개시의 범위와 사상 내에 있는 다른 실시예들이나 개선사항들을 인식할 수 있을 것이다. 따라서, 특정한 구조, 행위들 또는 매체들은 본 개시를 구현하는 예시적인 실시예들로서 개시된다. 본 개시는 첨부된 청구범위에 의해 정의된다.

Claims

상태 데이터를 클라이언트로 푸쉬하기 위한 컴퓨터로 구현되는 방법으로서,
서버에서 상태 업데이트를 수신하는 단계와,
상기 상태 업데이트를 수신하는 것에 응답하여 상기 서버에서 상기 상태를 변경하는 단계와,
상기 서버에서 상기 상태를 해싱(hashing)하는 단계와,
상기 서버 상에서 상기 상태의 해시인 토큰을 생성하는 단계와,
상기 클라이언트로부터 토큰을 수신하는 단계와,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이한지를 판단하는 단계와,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이한 경우, 상기 서버 상의 토큰과 함께 상태 데이터를 상기 클라이언트로 푸쉬하는 단계
를 포함하는 상태 데이터를 클라이언트로 푸쉬하는 방법.
제1항에 있어서,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이한지를 판단하는 단계는 상기 서버 상의 토큰의 값과 상기 클라이언트로부터 수신된 토큰의 값이 상이한지를 판단하는 단계를 포함하는
상태 데이터를 클라이언트로 푸쉬하는 방법.
제1항에 있어서,
상기 클라이언트로부터 상태 업데이트에 대한 요청을 수신하는 단계 - 상기 클라이언트로부터 수신된 토큰은 상태 업데이트에 대한 상기 요청의 파라미터임 -
를 더 포함하는 상태 데이터를 클라이언트로 푸쉬하는 방법.
제3항에 있어서,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이하지 않은 경우, 상기 클라이언트로부터 수신된 상기 요청 및 상기 수신된 토큰을 유지하는 단계
를 더 포함하는 상태 데이터를 클라이언트로 푸쉬하는 방법.
제3항에 있어서,
상기 클라이언트로부터 수신된 토큰의 값은 비어 있는
상태 데이터를 클라이언트로 푸쉬하는 방법.
제5항에 있어서,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 빈 토큰 값이 상이한지를 판단하는 단계와,
상기 서버 상의 토큰과 함께 상태 데이터를 상기 클라이언트로 푸쉬하는 단계
를 더 포함하는 상태 데이터를 클라이언트로 푸쉬하는 방법.
제5항에 있어서,
상기 빈 값에 응답하여, 소정 시간 동안 상기 서버 상의 토큰과 함께 상기 상태 데이터를 상기 클라이언트에 푸쉬하는 단계
를 더 포함하는 상태 데이터를 클라이언트로 푸쉬하는 방법.
프로세서에 의해 실행될 때 상태 데이터에 대해 서버를 폴링(polling)하는 방법을 수행하는 컴퓨터 실행가능 명령어를 저장한 하나 이상의 컴퓨터 저장 매체로서,
상기 방법은
클라이언트에 의해 상기 서버에서의 상기 상태 데이터에 대한 제1요청을 전송하는 단계와 - 상기 제1요청은 제1토큰을 포함함 -,
제2토큰과 함께 상기 상태 데이터를 수신하는 단계와,
상기 수신된 상태 데이터가 상기 클라이언트에 저장된 상태 데이터와 상이한지를 판단하기 위해 상기 제1토큰 및 상기 제2토큰을 비교하는 단계와,
상기 제1토큰 및 상기 제2토큰이 상이한 경우, 상기 클라이언트에 저장된 상기 상태 데이터를 업데이트하는 단계
를 포함하는
하나 이상의 컴퓨터 저장 매체.
제8항에 있어서,
상기 폴링은 토큰 메커니즘을 통한 HTTP(Hypertext Transfer Protocol) 롱 폴링(long polling)을 포함하는 하나 이상의 컴퓨터 저장 매체.
토큰 메커니즘을 통해 서버에서의 상태 데이터를 클라이언트로 푸쉬하는 시스템으로서,
프로세서와,
상기 프로세서에 결합되어 상기 서버 내의 관리 모듈을 제공하기 위해 프로세서에 의해 실행될 수 있는 컴퓨터 프로그램 명령어를 포함하는 메모리
를 포함하되,
상기 관리 모듈은
상태 업데이트를 수신하고,
상기 상태 업데이트를 수신하는 것에 응답하여 상기 상태를 변경하고,
상기 상태를 해싱하고,
상기 서버 상에서 상기 상태의 해시인 토큰을 생성하고,
상기 클라이언트로부터 토큰을 수신하고,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이한지를 판단하고,
상기 서버 상의 토큰과 상기 클라이언트로부터 수신된 토큰이 상이한 경우, 상기 서버 상의 토큰과 함께 상태 데이터를 상기 클라이언트로 푸쉬하도록 구성되는
시스템.