문맥 (context)
본 발명은 요청-응답 전송을 사용하여 신뢰성있게 메시지들을 전달하기 위한 시스템, 방법 및 컴퓨터 프로그램 제품들에 관한 것이다.
컴퓨터 시스템이 점차 증가함에 따라, 크고 작은 네트워크들 모두에서 파일들 및 컴퓨터 시스템들의 프로세싱 자원들을 분산할 필요성도 증가하고 있다. 일반적으로, 컴퓨터 시스템 및 관련된 장치들은 다양한 이유, 예를 들어 사적인 전자 메시지들의 교환, 상품 판매, 계정 정보의 제공 등을 위해 네트워크를 통해 정보를 전달한다. 그러나, 컴퓨터 시스템들 및 그들의 관련된 어플리케이션들이 점차 복잡해짐에 따라, 네트워크 상의 데이터 및 자원들의 공유와 연관된 도전들도 증가하고 있다는 것을 이해할 것이다.
일반적으로, 둘 이상의 컴퓨터 시스템들 사이에서 파일 및 자원들을 분산시키는 다수의 서로 다른 메커니즘 및 프로토콜들이 존재한다. 예를 들어, 메시지들은, 하나 이상의 다른 컴퓨터 시스템들이 반드시 응답할 필요가 없는 방식으로 한 컴퓨터 시스템에서 그 다른 컴퓨터 시스템들로 송신될 수 있다. 이러한 것의 일례는, 전자 메일 메시지들을 송신하거나, 또는 소정의 컨텐츠를 UDP(user datagram protocol)을 사용하여 다른 컴퓨터들로 스트리밍하는 경우에 사용될 수 있는 것과 같은, 비접속형(connectionless) 프로토콜들이다. 파일들 또는 자원들을 공유하는 다른 방법들은, TCP(transmission control protocol)를 사용하는 것과 같은 접속-지향 프로토콜들의 사용을 포함할 수 있다. 접속-지향 통신은 통상적으로 일련의 요청들 및 응답들을 통해 접속을 확립하고, 소정의 접속 상태 정보를 송신하는 것을 수반한다. 컴퓨터들로 송신되고 그로부터 수신되는 데이터는 일반적으로 전송된 데이터와 접속을 연관시키는 소정의 요소를 가진다.
접속-지향 통신은, 소정의 어플리케이션들에 대한 비접속형 통신과 구별되는 다수의 이점을 가진다. 예를 들어, TCP를 사용하여 개시되는 접속은, 모든 데이터가 일단에서 수신되었다는 것을 보장할 뿐만 아니라 소정량의 에러 정정을 보장하는 다수의 기능들을 제공한다. 예를 들어, 송신 컴퓨터는 패킷이 20 패킷들 중 첫번째라는 것을 나타내는 패킷을 송신할 수 있다. 수신 컴퓨터는 접속 세션에서 모든 20 패킷들을 수신한 후, 20 패킷들 모두가 수신되었다는 것을 나타내는 확인(또는 "ack")을 송신 컴퓨터 시스템에 제출한다. 소정의 경우, 수신 컴퓨터 시스템은 심지어 수신된 각 패킷에 대한 ack를 송신할 수도 있다. RM(reliable messaging) 메커니즘을 사용하는 경우, 송신 컴퓨터 시스템이 각 패킷에 대한 ack 또는 20 패킷 모두에 대한 ack를 수신하지 못하면, 송신 컴퓨터 시스템은 전체 메시지를 다시 송신하거나 또는 심지어 수신 컴퓨터에 필요한 개별적인 패킷들을 재송신할 수 있다.
이와 같이, HTTP(Hypertext Transfer Protocol) 및 FTP(File Transfer Protocol)과 같은 다수의 서로 다른 프레이밍(framing) 프로토콜들은 각각 접속 지향 전송 프로토콜들의 상부에 계층화되어 앞서 언급한 이러한 속성들 중 하나 이상을 이용한다. 예를 들어, 클라이언트 컴퓨터가 HTTP를 사용하여 정보를 검색할 때, 그 클라이언트 컴퓨터는 웹 서버와의 TCP 접속을 확립하고, 예를 들어 클라이언트가 음악을 온라인으로 구매하여 자신에게 송신할 것을 웹 서버에게 요청하는 온라인 상거래의 경우에서 웹 서버가 소정의 조치를 취하라는 요청, 또는 HTML 파일 또는 이미지와 같은 자원에 대한 HTTP 요청을 송신한다. 웹 서버는 요청을 수신하고 대응하는 응답을 제공하는데, 이 응답은 요청 파일의 콘텐츠를 포함할 수 있다. 요청된 파일들을 수신한 후, 또는 웹 서버와의 통신이 완료되었다고 클라이언트 컴퓨터가 결정하는 경우, 클라이언트 컴퓨터는 TCP 접속을 차단한다. 이와 같이, 클라이언트는 서비스의 관점에서 위치를 알 수 있어야 할(addressable) 필요가 없다. 예를 들어, 클라이언트는 NAT(Network Address Translation) 서버 뒤에 있을 수 있거나, 또는 방화벽을 가로질러 접속을 연결(bridge)하는 HTTP 프록시를 사용할 수 있다. 다른 이점은, 요청들 및 응답들이 용이하게 상관된다는 것인데, 각 응답은 그에 선행된 요청에 상관된다.
지시문 (instruction)
주어진 원문을 읽고 필요한 정보를 파악하여, 원문에 근거해 질문에 답하라.
질문 (question)
HTTP 및 FTP와 같은 프레이밍 프로토콜은 어떤 계층 구조를 통해 통신 속성을 이용하는가?
추론 과정 (compact_reasoning)
-
1과제 해석
task_interpretation프레이밍 프로토콜(HTTP, FTP)과 다른 프로토콜 간의 계층적 관계를 묻는 질문으로 해석한다.
-
2정보 추출
information_extractionHTTP 및 FTP가 언급된 문장을 찾아 계층 관계 정보를 추출한다.
- HTTP(Hypertext Transfer Protocol) 및 FTP(File Transfer Protocol)과 같은 다수의 서로 다른 프레이밍(framing) 프로토콜들은 각각 접속 지향 전송 프로토콜들의 상부에 계층화되어 앞서 언급한 이러한 속성들 중 하나 이상을 이용한다.
-
3근거 선택
evidence_selection프레이밍 프로토콜이 무엇의 상부에 계층화되어 있는지에 대한 직접적인 근거를 선별한다.
- 프레이밍(framing) 프로토콜들은 각각 접속 지향 전송 프로토콜들의 상부에 계층화되어
-
4논리 통합
logical_integration프레이밍 프로토콜이 접속 지향 전송 프로토콜의 상위 계층에 위치함을 확인하여 관계를 정리한다.
-
5결론 도출
conclusion_formulationHTTP와 FTP는 접속 지향 전송 프로토콜의 상부에 계층화되어 해당 프로토콜의 속성을 이용한다는 결론을 도출한다.
- 접속 지향 전송 프로토콜들의 상부에 계층화되어 앞서 언급한 이러한 속성들 중 하나 이상을 이용한다.
-
6답변 생성
answer_generation질문에 대해 계층적 위치 관계를 명확히 기술하여 답변을 작성한다.
- 접속 지향 전송 프로토콜들의 상부에 계층화되어
최종 답변 (final_answer)
HTTP 및 FTP와 같은 프레이밍 프로토콜들은 각각 접속 지향 전송 프로토콜들의 상부에 계층화되어 해당 프로토콜의 속성들을 이용한다.
핵심 해석 (core_interpretation)
HTTP 및 FTP와 같은 프레이밍 프로토콜들은 접속 지향 전송 프로토콜들의 상부에 계층화되어 있다.