KR102055535B1 - 탄성 패브릭 어댑터 - 무접속의 신뢰할 수 있는 데이터그램 - Google Patents

Abstract

타겟 애플리케이션과 명백한 연결을 수립하기 위해 유저 애플리케이션을 필요로 하지 않는 네트워크를 통한 연결 수립을 위한 시스템들 및 방법들이 제공된다. 일부 구현예들에서, 네트워크 및 호스트 디바이스와 통신하도록 구성된 장치가 제공된다. 장치는 호스트 디바이스로부터 메시지 및 메시지와 관련된 목적지 정보를 수신할 수 있다. 장치는 목적지 정보를 이용하여 복수의 전송 컨텍스트로부터 전송 컨텍스트를 추가로 결정할 수 있다. 전송 컨텍스트는 네트워크상의 목적지와의 연결 상태를 포함할 수 있다. 네트워크 상의 목적지는 목적지 정보와 연관될 수 있다.

Description

탄성 패브릭 어댑터 - 무접속의 신뢰할 수 있는 데이터그램{ELASTIC FABRIC ADAPTER - CONNECTIONLESS RELIABLE DATAGRAMS}

고성능 컴퓨팅은 즉, 하나의, 하이-파워 컴퓨팅 시스템으로서 기능하는 상대적으로 저 비용 컴퓨터들의 컴퓨터 클러스터(cluster)들에 의해 제공될 수 있다. 고성능 컴퓨팅은 전형적으로 클러스터내 시스템들을 연결하는 네트워크에 걸친 고 대역폭 및 저 레이턴시(latency)를 요구한다. 트랜잭션(transaction) 레이턴시는 시스템 송신 패킷들 및 시스템 수신 패킷들 둘 모두에서 프로세서들의 개입을 줄임으로써 축소될 수 있다. 패킷 송신에서 프로세서 개입을 줄이는 서버 메시지 프로토콜들은 RDMA(Remote Direct Memory Access) 프로토콜들 또는, 보다 일반적으로, 커널 바이패스 프레임워크(kernel bypass framework)를 갖는 프로토콜들로 지칭될 수 있다. 커널 바이패스 프레임워크를 갖는 프로토콜들은 전형적으로 송신과 수신 시스템 간에 통신하기 위해 전송 스택(transport stack)를 사용한다. 전송 스택은 네트워크로 나가는 송신 패킷들 및 네트워크로부터 들어오는 수신 패킷들에 대한 큐(queue) 쌍들을 포함할 수 있다. 전송 스택은 송신과 수신 시스템간에 연결을 관리하고, 뿐만 아니라 패킷들의 송신 및 수신을 관리하는 하나 이상의 전송 서비스들을 또한 포함할 수 있다.

본 개시에 따른 다양한 실시예들이 도면들을 참조하여 설명될 것이다 :
도 1은 컴퓨팅 자원들의 클러스터의 예를 예시한다;
도 2 는 커널 바이패스 프레임워크를 구현하기 위해 사용될 수 있는 통신 스택의 예를 예시한다;
도 3은 전송 서비스 유형들의 예들을 예시한다;
도 4 는 완화된 신뢰할 수 있는 데이터그램 전송(Relaxed Reliable Datagram transport)를 지원하도록 구성될 수 있는 시스템의 예를 예시한다;
도면들 5a-5b는 유저 애플리케이션이 나중에 메시지들을 다른 애플리케이션에 송신하기 위해 사용할 수 있는 어드레스 핸들(address handle)을 유저 애플리케이션이 획득할 수 있는 프로세스의 예를 예시한다;
도면들 6a-6b는 유저 애플리케이션이 메시지를 송신하기 위해 어드레스 핸들을 사용할 수 있는 프로세스의 예를 예시한다;
도면들 7a-7b는 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 포함하는 시스템들에 대해 구현될 수 있는 통신 스택의 예를 예시한다;
도 8은 이용 가능한 경로들에 걸쳐 더 큰 이용율을 달성하기 위해 완화된 신뢰할 수 있는 데이터그램 전송이 어떻게 네트워크에 걸친 다수의 경로들을 관리할 수 있는지의 예를 예시한다;
도면들 9a-9b는 완화된 신뢰할 수 있는 데이터그램 전송이 어떻게 신뢰할 수 있는 패킷들의 전달을 보장할 수 있는지의 예를 예시한다;
도면들 10a-10b는 플로릿(flowlet)들로 분할된 단일 패킷 플로우(flow), 및 패킷들이 수신 유저 애플리케이션에 의해 수신되는 순서의 예를 예시한다;
도 11은 네트워크에 걸쳐 메시지들을 송신하려고 하는 유저 애플리케이션에 대해 전송 컨텍스트(transport context)가 결정될 수 있는 프로세스의 예를 예시한다;
도 12는 어드레스 핸들을 획득하기 위한 프로세스 예를 예시한다;
도 13은 각각의 패킷이 전달되는 것을 보장하기 위해 각각의 패킷에 대한 상태를 모니터링하고 네트워크를 통하여 패킷들을 송신하기 위한 프로세스의 예를 예시한다;
도 14는 패킷이 수신된 것을 표시하기 위해 각각의 패킷에 대한 응답을 생성하고 네트워크를 통하여 패킷들을 수신하기 위한 프로세스의 예를 예시한다;
도 15는 본 출원에서 설명된 시스템들 및 방법들을 구현하기 위해 사용될 수 있는 네트워크 어댑터 디바이스의 예를 예시한다;
도 16은 일부 실시예들에 따른 하나 이상의 네트워크들을 통해 연결된 하나 이상의 서비스 제공자 컴퓨터들 및/또는 유저 디바이스를 포함하는 본 출원에 설명된 특징부들과 시스템들에 대한 일 예제 아키텍처를 예시한다.
도 17은 일부 실시예들에 따른 측면들을 구현하기 위한 예시 컴퓨팅 시스템의 환경의 측면들을 예시한다.

이하의 설명에서, 다양한 실시예들이 설명될 것이다. 설명의 목적을 위하여, 실시예들의 철저한 이해를 제공하기 위해 특정 구성들 및 세부사항들이 개시된다. 그러나, 본 실시예들이 특정 세부사항들 없이 실행될 수 있다는 것은 당업자에게 또한 자명할 것이다. 더욱이, 주지의 특징부들은 설명되는 실시예들을 모호하게 하지 않기 위해서 생략되거나 간략하게 될 수 있다.

고성능 컴퓨팅은 즉, 하나의, 하이-파워 컴퓨팅 시스템으로서 기능하는 상대적으로 저 비용 컴퓨터들의 컴퓨트 클러스터들에 의해 제공될 수 있다. 고성능을 제공하기 위해, 클러스터내 시스템들을 연결하는 네트워크는 고 대역폭을 지원해야 하고, 컴퓨터 클러스터내 시스템들간에 송신되는 메시지들은 가능한 최저의 레이턴시를 가져야 한다. 흔한 네트워킹 프로토콜들, 예컨대 TCP/IP(Transmission Control Protocol/Internet Protocol)는 일반적으로 대역폭을 최대화 그리고 레이턴시를 최소화하기 보다는 많은 상이한 유형들의 네트워크들에 걸쳐 상호운용성(interoperability) 쪽으로 배향된다. 고성능 컴퓨트 클러스터들은 따라서 일반적으로 커널 바이패스 프레임워크를 제공하는 서버 메시지 프로토콜들을 사용한다. 운영 체제(operating system) 커널 동작들을 바이패스하는 것은 네트워크 대역폭을 크게 개선시키고 송신 레이턴시를 줄일 수 있다. 커널 바이패스 프레임워크를 제공하는 네트워크 프로토콜들은 일반적으로 소위 RDMA(Remote Direct Memory Access) 프로토콜들이고, 하지만 대부분의 경우들에서 RDMA는 이들 프로토콜들에 의해 제공되는 단지 하나의 특징이다.

커널 바이패스 프레임워크를 제공하는 네트워크 프로토콜들은 일반적으로 네트워크 패킷들 송신 및 수신을 위해 전송 스택(transport stack)을 사용한다. 전송 스택은 전형적으로 하나 이상의 전송 서비스들을 제공한다. 이들 전송 서비스들은 일반적으로 연결되거나 또는 연결되지 않은, 및 신뢰할 수 있는 또는 신뢰할 수 없는 것으로 분류된다. 연결된 전송 서비스 유형들은 일반적으로 컴퓨팅 클러스터의 확장성에 부정적인 영향을 가진다. 연결된 전송 서비스들에 대하여, 클러스터에 연결된 시스템들의 수는 증가하고, 연결들의 수는 극적으로 증가할 수 있다. 신뢰할 수 있는 연결되지 않은 전송 서비스 유형들은 보다 확장가능할 수 있지만, 그러나 일반적으로 네트워크에서 드랍(drop)되는 패킷들에 대한 낮은 허용 오차(tolerance)를 가진다. 고성능 컴퓨팅 시스템은 따라서 무시가능한 패킷 드랍(packet drop)들의 비율 이상을 가질 수 있는 네트워크를 통하여 확장가능하고 신뢰할 수 있는 전송 서비스 유형에 의해 개선될 수 있다.

신뢰성(reliability)은 - 즉, 패킷들의 보장된 전달 - 네트워크 어댑터 디바이스(network adapter device)에서 가장 잘 핸들링 될 수 있다. 네트워크 어댑터는 언제 패킷들이 드랍되는 지를 빠르게 결정할 수 있고, 재송신될 해당 패킷들에 대한 요청들을 그만큼 빠르게 생성할 수 있다. 호스트 디바이스상에서 운영하는 소프트웨어가 신뢰성을 처리하면 레이턴시에 대해 부정적인 영향을 가질 수 있다. 소프트웨어가 신뢰할 수 있는 패킷 전달을 보장하기 위해서, 패킷들이 전송 스택까지 운영 체제 커널에 또는 유저 애플리케이션에 전달되어야 할 것이지만, 운영 체제가 사용중인 것과 같은 다양한 이유들 때문에 중간에서 지연될 수 있다. 패킷 신뢰성 동작들은 따라서 전송 스택을 횡단해야 하는 것에 의해 야기되는 잠재적인 지연들을 회피함으로써 보다 효율적으로 핸들링 될 수 있다.

그러나, 패킷 드랍들 및 패킷 재송신은 패킷들이 순서가 바뀌어서(out of order) 목적지 시스템에 도달하게 할 수 있다. 패킷 드랍들이 일어날 수 있는 시스템들에서, 순서가 바뀌어서 도달한 패킷들 재-순서화(re-ordering)는 전형적으로 예를 들어, 네트워크 어댑터 디바이스에서 패킷 전달을 보장하는 것과 함께 핸들링된다. 그러나 패킷 재순서화는 잠재적으로 계산 집약적이고(compute-intensive), 네트워크 어댑터 디바이스들은 전형적으로 저전력, 값이 싼 프로세서들을 가진다. 호스트 디바이스는, 반면에, 전형적으로 고성능 프로세서를 가지며, 용이하게 패킷 재순서화를 관리할 수 있다. 그러나, 이미 언급한 것과 같이, 호스트 디바이스 소프트웨어가 패킷 재순서화 및 신뢰할 수 있는 패킷 전달을 핸들링하게 하는 것은 비효율적일 수 있다.

신뢰할 수 있는 패킷 전달 및 패킷 재순서화를 제공하기 위한 시스템들 및 방법들이 본 출원에 개시되고, 신뢰성은 네트워크 어댑터 디바이스에서 핸들링되고 패킷 재순서화는 호스트 디바이스상의 소프트웨어에 의해 핸들링된다. 또한 완화된 신뢰할 수 있는 데이터그램 전송 서비스(Relaxed Reliable Datagram transport service)가 제공된다. 완화된 신뢰할 수 있는 데이터그램 전송은 간헐적으로 패킷들을 드랍할 수 있는 네트워크들에 걸쳐 패킷 전달을 보장하기 위한 메커니즘들을 제공한다. 완화된 신뢰할 수 있는 데이터그램 전송을 사용하도록 구성된 네트워크 어댑터 디바이스는 패킷들 버퍼링을 피할 수 있고, 대신에 그것들은 가능한 한 빠르게 호스트 디바이스에 전달할 수 있다. 그런 다음 호스트 디바이스가 요구된 패킷들을 재순서화할 수 있다. 본 출원에서 설명된 이들 시스템들 및 방법들은 클러스터에 걸쳐 고 대역폭 및 저 레이턴시 전송들을 제공함으로써 저 비용 컴퓨팅 클러스터상에서 고성능 컴퓨팅을 가능하게 할 수 있다.

컴퓨팅 자원들 클러스터링(clustering)은 더 작은 비용으로 더 나은 성능 및 확장성을 제공할 수 있다. 도 1은 컴퓨팅 자원들의 클러스터(100)의 예를 예시한다. 클러스터(cluster)는 스위치들로 연결되고, 병렬로 운용되도록 구성된 컴퓨팅 자원들의 그룹이다. 많은 구현예들에서, 다양한 컴퓨팅 자원들은 단일 로직 컴퓨팅 자원을 형성한다. 도 1에 예시된 예시 클러스터 (100)는 다수의 노드들 (102a-h) 및 스위치들 (104a-c)을 포함한다. 일부 구현예들에서, 클러스터 (100)는 라우터 (106)를 또한 포함할 수 있다.

도 1에 예시된 노드들 (102a-h)은 다양한 컴퓨팅 자원들을 나타낼 수 있다. 예를 들어, 하나 이상의 노드들 (102a-h)은 컴퓨터, 예컨대 서버 컴퓨터일 수 있다. 클러스터 애플리케이션들에 사용되는 컴퓨터들은 하나 이상의 프로세서들을 포함할 수 있고, 이들 프로세서들은 하나 이상의 프로세싱 코어들을 포함할 수 있다. 이들 컴퓨터들은 메모리 및 주변 디바이스들을 또한 포함할 수 있다. 일부 구현예들에서, 이들 컴퓨터들은 클러스터 (100) 내 스위치 (104a-c)를 연결하기 위해 어댑터 디바이스를 사용할 수 있다. 컴퓨팅 자원들의 다른 예들은 스토리지(storage) 디바이스들 (예를 들어, 하드 드라이브들), 스토리지 서브시스템들 (예를 들어, 스토리지 디바이스들의 어레이), 입력/출력 (I/O) 모듈들, 및 클러스터 (100)에 대한 운영(administration) 액세스를 위한 콘솔들을 포함한다.

스위치들 (104a-c)은 다양한 노드들 (102a-h) 간에 연결을 제공할 수 있다. 각각의 노드 (102a-h)는 스위치 (104a-c)로의 연결을 통하여 클러스터 (100)에 연결될 수 있다. 일부 경우들에서, 노드 (102a-h)는 하나 초과의 스위치 (104a-c)에 연결될 수 있다. 스위치들은 다른 스위치들에 또한 연결될 수 있다. 대부분의 경우에, 스위치 (104a-c)상에 임의의 포트는 노드 (102a-h) 또는 다른 스위치에 연결하기 위해 사용될 수 있다. 대부분의 구현예들에서, 클러스터 (100)의 사이즈는 더 많은 스위치들 및 노드들을 연결함으로써 빠르게 그리고 용이하게 확대될 수 있다.

스위치들 (104a-c)의 네트워크는 임의의 노드 (102a-h)로부터 임의의 다른 노드 (102a-h)로의 다수의 경로들을 제공할 수 있다. 스위치 (104a-c)는 다른 스위치 (104a-c)와 다수의 연결들을 가질 수 있고, 이는 스위치들 (104a-c) 간에 추가 경로들을 제공한다. 일부 경우들에서, 노드들 (102a-h)은 하나 초과의 스위치 (104a-c)에 연결될 수 있고 또한 더 많은 경로들을 생성한다. 하나의 노드 (102a-h)로부터의 패킷들은 동시에 다른 노드 (102a-h)에 도달하는 다수의 경로들을 사용할 수 있다. 대안적으로 또는 추가적으로, 하나의 노드 (102a-h)로부터 다른 노드 (102a-h)로의 패킷들은 단지 하나의 경로를 따를 수 있다. 일부 경우들에서, 각각의 스위치 (104a-c)에서 패킷이 어느 경로를 따를 지에 관한 결정이 이루어질 수 있다. 다른 경우들에서, 패킷의 경로는 전형적으로 소스 노드에서 미리 결정될 수 있다. 하나의 노드 (102a-h)로부터 다른 노드 (102a-h)로의 패킷들의 스트림(stream)은 패킷 플로우 또는 간단하게 "플로우(flow)"로 지칭될 수 있다. 일부 경우들에서, 예를 들어 패킷들이 함께 하나의 메시지를 형성할 때와 같이 플로우 내 패킷들은 연관된다.

일부 구현예들에서, 하나 이상의 스위치들 (104a-c)은 부하 분산 기능(load balancing functionality)을 포함할 수 있다. 이들 구현예들에서, 스위치들 (104a-c)은 효율적으로 네트워크 트래픽을 분산시키도록 구성될 수 있다. 목표는 전형적으로 노드들과 스위치들 사이의 링크(link)들이 혼잡(congest)되지 않고 패킷 트래픽이 가능한 한 빠르게 클러스터 (100)를 가로질러 흐르는 것을 보장하는 것이다. 많은 경우들에서, 그러나, 스위치들 (104a-c)은 그것들의 자체 트래픽 부하만을 알고, 다른 스위치들 (104a-c)에서의 부하에 가시성은 없다.

일부 구현예들에서, 클러스터 (100)는 라우터 (106)에 연결될 수 있다. 라우터 (106)는 다른 네트워크들 (108), 예컨대 다른 클러스터들 또는 서브-네트워크들 (subnets), LANs(Local Area Networks), WANs(Wide Area Networks), 또는 인터넷에 연결을 제공할 수 있다.

상호연결된 스위치들 (104a-c) (및 라우터 (106), 만약 존재한다면)은 스위치 패브릭(fabric), 패브릭, 또는 그 이상 간단히 “네트워크”로 지칭될 수 있다. 본 출원에, 용어들 “패브릭(fabric)” 및 “네트워크(network)”는 호환하여 사용될 수 있다.

컴퓨팅 클러스터, 예컨대 예시된 클러스터 (100)는 더 큰 컴퓨팅 파워 및 더 나은 신뢰성을 제공할 수 있다. 개별 컴퓨팅 자원들은 하나의 컴퓨터가 단독으로 해결할 수 없거나, 또는 단독으로 해결하는데 매우 긴 시간이 걸릴 수 있는 큰 문제를 해결하기 위해 협력하여 작업할 수 있다. 일부 경우들에서, 컴퓨팅 클러스터는 비용이 작고 덜 복잡하지만 슈퍼 컴퓨터에 유사한 성능을 제공할 수 있다. 컴퓨팅 클러스터에 의해 사용되는 스위치 패브릭 아키텍처는 고장 방지 능력(fault tolerance) 및 확장가능한 장점을 또한 가질 수 있다. 스위치 패브릭 아키텍처에서, 전형적으로 모든 링크는 링크의 각각의 엔드(end)에 부착된 하나의 디바이스를 가진다. 따라서, 각각의 링크는 많아야, 두개의 디바이스들의 행위에 단지 의존한다. 스위치 패브릭은 더 많은 스위치들을 추가함으로써 용이하게 또한 스케일링될 수 있고, 이는 더 많은 노드들을 부착시키기 위한 더 많은 포트들을 제공한다. 일부 경우들에서, 더 많은 스위치들을 추가하는 것은 클러스터의 총합 대역폭(aggregate bandwidth)을 증가시킬 수 있다. 노드들 사이의 다수의 경로들은 또한 총합 대역폭을 높게 유지할 수 있고, 링크 고장들의 경우에 이중화 연결(redundant connection)들을 제공한다.

컴퓨터 클러스터들은 다양한 애플리케이션들을 위해 사용될 수 있다. 예를 들어, 컴퓨팅 클러스터는 고성능 컴퓨팅을 위해 사용될 수 있다. 고성능 컴퓨팅은 계산 집약적인 애플리케이션들을 실행하기 위해 병렬 프로세싱을 이용하는 것을 수반한다. 과학 연구들, 기술자들, 및 학교 기관들은 복잡한 모델링 또는 시뮬레이션들, 예컨대 예를 들어 자동차 충돌 시뮬레이션들, 날씨 모델링, 원자 시뮬레이션들, 등등을 위해 고성능 컴퓨팅을 사용할 수 있다. 컴퓨팅 클러스터들에 대한 다른 예시 사용은 기계 학습, 금융 애플리케이션들, 분산 스토리지, 및 데이터베이스들을 포함한다. 기계 학습은 광대한 양의 데이터를 조사하는 것, 데이터로부터 학습할 수 있고 데이터로부터 예측들을 만들 수 있는 알고리즘을 실행시키는 것을 수반한다. 금융 애플리케이션들, 예컨대 초단타 매매(high-frequency trading)는 큰 양의 데이터를 조사할 수 있고, 일반적으로 데이터에 변화들에 빠르게 반응하는 것에 의존한다(예를 들어, 사람보다 훨씬 더 빠르게). 분산 스토리지(distributed storage)는 매우 큰 양의 데이터가 다수의 위치들로부터 액세스되는 것을 허용한다. 스토리지 영역 네트워크들은 분산 스토리지의 일 형태이다. 데이터베이스들은 또한 큰 양의 데이터를 저장하고, 데이터베이스내에 저장된 특정 정보 위치를 찾는 매우 빠른 방법들을 제공해야 한다.

컴퓨팅 자원들 클러스터링으로부터의 대부분의 장점을 달성하기 위해, 노드들 간에 통신을 위해 사용되는 프로토콜은 고 대역폭 및 저 레이턴시를 제공해야 한다. 고 대역폭은 큰 볼륨(volume)의 트래픽이 클러스터를 횡단할 수 있어야 한다는 것을 의미하고, 저 레이턴시는 트래픽이 소스로부터 목적지로 가능한 한 빠르게 이동할 수 있어야 한다는 것을 의미한다. 몇몇의 동작들이 레이턴시에 주요한 기여자들일 수 있다. 이들은 운영 체제내에 네트워크 프로토콜 코드를 실행시킴으로써 야기되는 오버헤드(overhead), 데이터를 발송하기 위해 그리고 커널 모드로 들어가고 그리고 커널 모드를 빠져나가기 위해 요구되는 컨텍스트 스위치(context switch)들, 및/또는 네트워크 어댑터에서 유저-레벨 버퍼들과 메모리 사이의 데이터의 과잉 복사를 포함한다. 예를 들어, 전형적인 네트워크 프로토콜 스택은 혼잡되지 않고(non-congested), 거의-제로-지연 네트워크를 가정하여 대략 100 마이크로초의 라운드-트립(round-trip) 레이턴시를 유발할 수 있다. 그러나, 이 지연은 스케줄링 지연들 때문에 밀리세컨드 길이 스파이크(spike)들, 애플리케이션이 네트워크 스택 이슈들을 회피하도록 디자인되지 않은 때 수십 밀리세컨드 길이 스파이크들, 및/또는 패킷들이 혼잡된 링크상에서 드랍된 때 초-길이 지연들로 보다 전형적으로 악화될 수 있다. 컴퓨팅 클러스터들은 고-대역폭 하드웨어로 디자인될 수 있고, 고-대역폭 하드웨어는 전형적으로 프로세서 및 메모리 복사 오버헤드(overhead)에 더 민감하다.

네트워킹 프로토콜들 예컨대 (TCP/IP)는 많은 상이한 유형들의 네트워크들에 걸친 양호한 성능에 초점이 맞추어진 경향이 있고, 및/또는 비용-효율적이다. 결과적으로, 프로토콜들 예컨대 TCP/IP는 고 레이턴시를 갖는 경향이 있고 복잡해지는 경향이 있다. While 네트워크 프로토콜들 예컨대 TCP는 가변 유형들의 네트워크들에 대한 범용 통신에 적절할 수 있고, 고-대역폭, 저-레이턴시 환경들은 보다 특화된 프로토콜들에서 유리할 수 있다.

가상 인터페이스 (VI : Virtual Interface) 아키텍처 (VIA : VI Architecture) 서버 메시지 프로토콜들이 컴퓨팅 클러스터내 노드들 간에 고 대역폭, 저 레이턴시 링크들을 제공하기 위해 개발되었다. VIA에 유사한 프로토콜들의 예들은 InfiniBand, iWARP(Internet Wide Area RDMA Protocol), 및 RoCE(RDMA over Converged Ethernet )를 포함한다. 각각의 이들 프로토콜들은 이하에서 보다 상세하게 설명될 흔히 RDMA로 지칭되는 커널 바이패스 프레임워크(kernel bypass framework)를 포함한다. iWARP는 TCP/IP 프로토콜 상에서 커널 바이패스 프레임워크를 제공한다. RoCE는 이더넷-유형 네트워크들 상에서 커널 바이패스 프레임워크를 제공한다. InfiniBand는 InfiniBand-특정 네트워크 상에서 커널 바이패스 프레임워크를 제공한다. 때때로 용어들 “InfiniBand” 및 “RDMA”은 호환하여 사용되지만, 그러나 다른 프로토콜들 (예컨대 iWARP 및 RoCE)도 또한 RDMA-스타일, 커널 바이패스 프레임워크를 제공한다.

VIA-유형 프로토콜들은 일반적으로 저 레이턴시, 고 대역폭, 및 커널-바이패스 네트워킹을 제공한다. VIA-유형 프로토콜들은 적어도 이하를: 다수의 유저 애플리케이션들간에 자원 공유에 의해 야기되는 오버헤드 줄이기, 프로세서로부터 전송 프로토콜 핸들링 작업 제거, 데이터의 더 빠른 벌크 전송들, 및 원격 애플리케이션 대기하는데 소비되는 시간 줄이기 제공하는 것을 목표로 한다.

VIA-유형 프로토콜들은 다수의 유저 애플리케이션들 간에 자원 공유에 의해 야기되는 오버헤드를 줄이는 것이 목표이다. 전형적인 네트워크 프로토콜 스택들은 커널 레벨에서 동작하고, 다수의 애플리케이션들 간에 네트워크 인터페이스의 공유를 가능하게 한다. 이 자원 공유는, 그러나, 적어도 이하의 이유들로 네트워크 지연을 유발할 수 있다: 다수의 프로세서 코어들간에 조정이 레이턴시를 추가할 수 있다; 애플리케이션을 깨우기(wake) 위해 사용되는 인터-프로세서 인터럽트(interrupt)들이 레이턴시를 추가할 수 있다; 중간 큐잉 또는 버퍼링이 애플리케이션들을 서로로부터 보호하기 위해 필요로 될 수 있다, 및 큐들 또는 버퍼들 간에 복사가 레이턴시를 추가할 수 있다; 및 DMA(Direct Memory Aceess)가 이들 애플리케이션들에 대해 구성되지 않을 수 있기 때문에 내부 커널 버퍼들은 애플리케이션 버퍼들로부터 또는 애플리케이션 버퍼들로 복사되는 것이 요구될 수 있다.

단일 네트워크 인터페이스를 공유하려고 하는 다수의 유저 애플리케이션들에 의해 야기되는 지연들을 피하기 위한 한가지 방법은 네트워크 인터페이스가 한번에 단지 하나의 애플리케이션에 의해 사용되게 하는 것이다. 데이터 DPDK(Data Plane Development Kit)는 이것을 가능하게 하는 프레임워크의 일 예를 제공한다. DPDK 프레임워크는 유저-스페이스 폴링 모드 디바이스 드라이버의 형태로 간단한 네트워크 인터페이스를 제공할 수 있다. DPDK 프레임워크는 또한 다른 운영 체제 서비스들을 대신할 수 있고, 그렇게 함으로써 유저 애플리케이션들에 애플리케이션 프로그래밍 인터페이스 (API) 를 제공하고 단일-유저 협력 멀티-태스킹을 위해 디자인된 모델을 실행시킨다. 이 프레임워크는 네트워크 인프라스트럭처 (예를 들어, 게이트웨이 디바이스들)에 효율적일 수 있지만 통상의 유저 애플리케이션들 및 미들웨어에 대해 실용이지 않을 수 있고, 이는 DPDK-특정 API를 수용하기 위해 재기록될 것을 요구할 수 있다. DPDK 프레임워크는 또한 운용하기 위해 원천 권한(root privileges)을 요구할 수 있고, 이는 커널에 부담(burden)을 지울 수 있고 보안 위험을 제기할 수 있다. 더욱이, DPDK 프레임워크는 멀티-유저 환경에서 실용적이지 않을 수 있는데, 이는 DPDK 환경은 애플리케이션들이 물리적 메모리 어드레스들을 사용하는 것을 필요로 할 수 있고 이는 가상 기계들의 사용을 제한하기 때문이다. 심지어 단일 유저에 대하여도, DPDK 프레임워크는 또한 비실용적일 수 있다. DPDK 및 유사한 모델들은 전송 스택의 책임을 떠맡기 위해 확장될 수 있고, 그렇게 함으로써 다수의 애플리케이션들을 서비스할 수 있다. 그러나, 이들 애플리케이션들과 DPDK 프로세스 간의 통신은 상당한 레이턴시를 초래할 수 있다.

하드웨어 자원들을 효율적으로 공유하기 위한 다른 방법은 커널 바이패스 프레임워크, 흔히 상기에서 언급한 바와 같이, RDMA 프레임워크로 불리운다. RDMA기반 디바이스들은 권한 없는(non-privileged) 유저 애플리케이션들에 의해 사용될 수 있다. RDMA기반 디바이스들은 또한 다수의 애플리케이션들이 서로의 간섭 없이 하드웨어를 직접 액세스하는 것을 허용할 수 있다. RDMA 디바이스들은 초기화를 수행하는 제어 동작들에 대해, 인터럽트 핸들링(interrupt handling)을 위해 요구될 수 있는 일부 조정에 대해서만 의존할 수 있고, 그러나 그 외에는, RDMA 디바이스는 커널과 무관하게 동작할 수 있다. 이것은 프로세서가 RDMA 동작들에 수반될 필요가 없다는 것을 의미한다. RDMA 프레임워크들은 또한 최적화 예컨대 폴링-모드(polling mode) 완료 핸들링을 제공할 수 있고, 이는 초-저 레이턴시를 제공하기 위해 유익할 수 있다.

상기에서 언급한 바와 같이, VIA-유형 프로토콜들은 전송 프로토콜을 관리하는 데 프로세서 개입을 줄이는 것이 목표이다. 앞에서 논의된 것처럼, 네트워크 프로토콜을 관리하는 데 프로세서 개입은 레이턴시의 잠재적인 소스이다. 애플리케이션이 원격 목적지로 긴 메시지를 발송할 때, 로컬 및 원격 컴퓨터들 양쪽에서 프로세서들이 관여될 가능성이 있다. 예를 들어, 프로세서들은 메시지를 패킷들로 분할하고, 송신을 위해 패킷들을 개별적으로 하드웨어 큐에 제출하고, 패킷들을 수신하고, 확인 응답(acknowledgment) 패킷들을 생성하고, 호스트 메모리에 데이터를 둘 곳을 결정하기 위해 요구될 수 있다. 특별히, 패킷이 도달한 때, 간단한 네트워크 인터페이스 카드는 주변기기 버스를 통하여 호스트 디바이스의 주 메모리로 패킷을 전달할 수 있고, 그런 다음 프로세서에 인터럽트를 발행하고, 인터럽트는 실제로 프로세서에 알리는데 얼마의 시간이 걸릴 수 있다. 일단 인터럽트된 후에, 프로세서는 그런 다음 일반적으로 운영 체제에 의해 야기되는 추가 지연 후에 프로토콜 프로세싱 동작들, 예컨대 확인 응답들을 생성을 실행할 수 있다.

프로토콜 동작들을 핸들링하도록 구성된 네트워크 어댑터는, 프로세서에 대한 이들 동작들을 제거하여, 각각의 패킷의 더 빠른 핸들링을 허용할 수 있다. 네트워크 어댑터 디바이스는 착신 메시지 및 원격 판독 및 기록 명령들을 프로세스할 수 있다. 네트워크 어댑터는 또한 호스트 메모리에 DMA 트랜잭션들을 수행하고 확인 응답 패킷들을 생성할 수 있다. 네트워크 어댑터는 프로세서 인터럽트 없이 이들 동작들을 수행할 수 있다.

앞에서 언급된 바와 같이, VIA-유형 프로토콜들의 다른 목표는 데이터에 더 빠른 벌크 전송들을 제공하는 것이다. 데이터의 벌크 전송들, 즉, 큰 블럭들의 데이터의 전송들은 간단히 네트워크 링크들의 대역폭을 증가시킴으로써 더 빠르게 실행될 수 있다. 고속 네트워크 상호연결들은 그러나, 소스 및/또는 목적지 컴퓨터들의 메모리 서브시스템상에 부담(burden)을 지울 수 있다. 메모리 서브시스템들은 전형적으로 오버프로비저닝되지 않고, 중간 복사본들이 메모리에 놓이게 되는 고-대역폭 네트워크 전송들 중에 여러번 액세스될 때 병목(bottleneck)이 될 수 있다. 벌크 전송이 다수의 복사본이 만들어지는 것을 필요로 할 때, 이 복사본은 전송 스루풋을 제한할 수 있고, 이는 트랜잭션 레이턴시를 증가시킬 수 있다. 이 지연을 완화시키기 위한 한 가지 방법은 큰 레벨 3 (L3) 캐시들을 포함하는 프로세서들에 의해 제공된다. 이들 프로세서들은 네트워크 인터페이스 카드들이 L3 캐시에 직접 데이터를 기록하게 할 수 있다. 이들 프로세서들은, 그러나, 캐시들의 성질때문에 (캐시에 없는 데이터가 페치(fetch)되는 것을 요구하여, 따라서 레이턴시를 초래한다) 비지속적으로 수행할 수 있다. 더욱이, 데이터가 빠르게 복사되지 않은 때, L3 캐시는 도움이 되지 않을 수 있는데, 이는 데이터가 더 유용한 데이터를 위하여 사용될 수 있는 L3 캐시내 공간을 차지할 수 있기 때문이다.

커널 바이패스 프레임워크들은 흔히 소위 “제로 복사(zero copy)” 데이터 전송으로 불리는 프로세스를 통하여 더 나은 해결책을 제공한다. 제로 복사는 RDMA에 의해 제공되는 동작들 중 하나이다. RDMA는 DMA(Direct Memory Access)의 확장을 설명한다. DMA는 전형적으로 어떤 하드웨어 서브시스템들이 프로세서를 이용하지 않고서 메인 시스템 메모리를 액세스하는 것을 허용한다. 유사하게, RDMA는 하나의 컴퓨터가 어느 컴퓨터에 프로세서를 수반하지 않고서 네트워크를 통하여 다른 컴퓨터상에 메모리를 액세스하는 것을 허용한다. 따라서, 로컬 컴퓨터는 중간 복사본들이 로컬 또는 원격 컴퓨터에서의 프로세서에 의해 만들어지지 않고서 원격 컴퓨터의 메모리상에서 판독, 기록 또는 원자 조작(atomic operation)들을 수행할 수 있다. 많은 구현예들에서, RDMA는 로컬 컴퓨터에 의해 가능하게 되고 원격 컴퓨터 각각은 RDMA 어댑터를 가진다.

앞에서 언급된 바와 같이, VIA-유형 프로토콜들은 또한 원격 애플리케이션을 대기하는 데 소비하는 시간을 줄이려고 한다. 애플리케이션들 그 자체가 네트워크 레이턴시에 기여할 수 있다. 네트워크 트랜잭션들은 로컬 컴퓨터에서 및 원격 컴퓨터에서 양쪽에서 애플리케이션을 수반할 수 있다. 원격 애플리케이션은 예를 들어, 스케줄링 지연들 때문에 트랙잭션들에 응답하는데 얼마의 시간이 걸릴 수 있다. 단지 로컬 애플리케이션만이 수반되는 “일-측(One-sided)” RDMA 통신은 원격 애플리케이션을 대기함으로써 야기되는 레이턴시를 줄일 수 있다. 그것의 메모리에 대한 액세스를 허용함으로써, 원격 애플리케이션은 데이터 전송에 수반될 필요가 없을 수 있다. 대신에, 원격 컴퓨터에서 RDMA 어댑터는 원격 애플리케이션을 수반하지 않고서 원격 메모리를 직접 액세스할 수 있다. RDMA는 판독 및 기록 동작들에 추가하여 원격 원자 조작들을 추가로 제공할 수 있고, 이는 동작들을 락킹(lock)함으로써 야기되는 레이턴시를 줄일 수 있다.

요약하여, VIA-유형 프로토콜들은 다수의 유저 애플리케이션들 간에 자원 공유에 의해 야기되는 오버헤드를 줄일 수 있다. VIA 프로토콜들은 프로세서로부터 전송 프로토콜 핸들링의 작업을 또한 제거할 수 있다. 이들 프로토콜들은 더 빠른 데이터의 벌크 전송을 또한 제공할 수 있고, 응답을 위해 원격 애플리케이션을 대기하는 소비하는 시간을 줄일 수 있다. 이들 동작들은 흔히 RDMA 동작들로서 설명되지만, 그러나 그것들은 커널 바이패스 동작들로서 더 일반적으로 설명될 수 있다. 이들 특징들은 원격 메모리 액세스 (RMA) 또는 일-측 통신으로 또한 지칭될 수 있다.

도 2 는 커널 바이패스 프레임워크를 구현하기 위해 사용될 수 있는 통신 스택(200)의 예를 예시한다. 도 2에 예시된 것과 같은 통신 스택 (200)을 이용하여, 클라이언트 프로세스 (202)는 로컬 시스템 (230) 또는 원격 시스템 (232)에서의 프로세서로부터의 도움 없이 원격 시스템 (232)상에 원격 프로세스 (204)와 직접 통신할 수 있다. 도 2의 예제는 두개의 상이한 시스템들상에서 실행하는 두개의 프로세서들 사이에 통신 스택(200)을 일 예로서 예시한다. 이하에 설명될, 유사한 통신 스택은 네트워크 패브릭 (220)을 가로질러 통신하는 임의의 두개의 프로세스들 사이에서 구성될 수 있다. 또한, 하나의 시스템 (230)은 “로컬(local)”로 불리우고 다른 시스템 (232)은 “원격(remote)”으로 불리지만, 일부 구현예들에서 통신 스택 (200)은 또한 반대 방향에서 동작할 수 있어서, 원격 시스템 (232)이 로컬 시스템 (230)에 보내진 메시지를 발원할 수 있다는 것이 이해되어야 한다.

일부 구현예들에서, 도 2에 예시된 통신 스택 (200)은 로컬 (230) 또는 원격 (232) 시스템 어느 하나에서 프로세서의 최소 사용으로 동작한다. 프로세서들로부터 네트워크 트래픽 제어 듀티(duty)를 제거하거나 또는 줄이는 것은 또한 “작업 큐 쌍들” 또는 간단히 “큐 쌍들” (210a-b)로 불리우는 “작업 큐들(work queues)”을 통하여 성취될 수 있다. 로컬 시스템 (230)과 원격 시스템 (232) 사이의 각각의 통신 채널에 대하여, 큐 쌍 (210a-b)은 양쪽 시스템들 (230,232)에 할당될 수 있다. 큐 쌍 (210a-b)은 네트워크 패브릭 (220)으로 향하는 트래픽을 위한 발송 큐 (212a-b), 및 네트워크 패브릭 (220)으로부터 착신하는 트래픽을 위한 수신 큐 (214a-b)를 포함한다. 일부 구현예들에서, 클라이언트 프로세스 (202)는 원격 프로세스 (204)와 통신 채널을 수립할 때 큐 쌍 (210a-b)을 개시한다. 이들 구현예들에서, 클라이언트 프로세스 (202)는 동일한 원격 프로세스 (204)와, 동일한 원격 시스템 (232)상에서 운용하는 프로세스들과, 또는 다른 원격 시스템들상에서 운용하는 프로세스들과 통신하기 위해 추가 작업 큐들을 개시할 수 있다. 클라이언트 프로세스들 및 원격 프로세스들은 비-커널 또는 운영 체제 프로세스들, 예컨대 유저 애플리케이션들 및/또는 드라이버 프로그램들을 포함한다.

일부 구현예들에서, 로컬 시스템 (230)에서 큐 쌍 (210a)은 소스 채널 어댑터 (208a)상에 존재한다. 소스 채널 어댑터 (208a)는 네트워크 패브릭 (220)와 통신하도록 구성될 수 있다. 소스 채널 어댑터 (208a)는 다른 프로세스들에, 동일한 클라이언트 프로세스 (202)에 할당되거나, 또는 현재는 사용되지 않을 수 있는 추가 큐 쌍들을 포함할 수 있다. 일부 구현예들에서, 큐 쌍 (210a)의 사용 및 구조는 명확하게 이해될 수 있고, 따라서 큐 쌍 (210a)은 하드웨어로 구현될 수 있다. 다른 구현예들에서, 큐 쌍 (210a)은 소프트웨어 (예를 들어, 드라이버로) 또는 하드웨어 및 소프트웨어의 조합으로 구현될 수 있다. 큐 쌍 (210a)에 추가하여, 소스 채널 어댑터는 전송 계층 (216a)을 또한 포함할 수 있고, 이는 네트워크 패브릭 (220) 및 원격 프로세스 (204)과 통신을 관리한다. 소스 채널 어댑터 (208a)는 소스 채널 어댑터 (208a)를 패브릭 (220)에 연결하는 물리적 포트 (218a)를 또한 포함할 수 있다. 소스 채널 어댑터 (208a)는 호스트 채널 어댑터로, 또는 더 일반적으로 네트워크 어댑터로 또한 지칭될 수 있다.

클라이언트 프로세스 (202)가 “작업 큐 엘리먼트(work queue element)” (222)를 (흔히 WQE로 축약된) 로컬 발송 큐 (212a)에 배치함으로써 원격 프로세스 (204)로 트랜잭션을 개시할 수 있다. 작업 큐 엘리먼트 (222)는 트랜잭션, 예컨대 판독, 기록, 또는 원자 트랜잭션을 포함할 수 있다. 일부 구현예들에서, 작업 큐 엘리먼트 (222)는 트랜잭션의 타겟으로 원격 프로세스 (204)를 식별하는 정보를 또한 포함할 수 있다. 소스 채널 어댑터 (208a)는 발송 큐 (212a)로부터 직접 작업 큐 엘리먼트 (222)를 프로세스할 수 있다. 소스 채널 어댑터 (208a)는 작업 큐 엘리먼트 (222)내 정보를 이용하여 하나 이상의 패킷들을 생성할 수 있다. 전송 계층 (216a)은 포트 (218a)를 통하여 네트워크 패브릭 (220)로 이들 하나 이상의 패킷들을 송신할 수 있다.

원격 시스템 (232)은 그것 자체의 목적지 채널 어댑터 (208b) (또한 타겟 채널 어댑터 또는 보다 일반적으로 네트워크 어댑터로 불리우는)에서 네트워크 패브릭 (220)으로부터 패킷 또는 패킷들을 수신할 수 있다. 소스 채널 어댑터 (208a)와 같이, 목적지 채널 어댑터 (208b)는 목적지 채널 어댑터를 네트워크 패브릭 (220)에 연결하는 포트 (218b)를 포함한다. 목적지 채널 어댑터 (208ab)는 전송 계층 (216b)를 또한 포함할 수 있고, 이는 네트워크 패브릭 (220) 및 클라이언트 프로세스 (202)와 통신을 관리한다. 목적지 채널 어댑터 (208b)는 원격 프로세스 (204)에 할당된 큐 쌍 (210b)을 또한 포함할 수 있다.

네트워크 패브릭 (220)로부터 원격 시스템 (232)에서 수신된 패킷 또는 패킷들은 전송 계층 (216b)에 의해 수신 큐 (214b)로 보내질 수 있다. 일부 구현예들에서, 목적지 채널 어댑터 (208b)는 클라이언트 프로세스 (202)에 의해 생성된 메시지 (222)를 리어셈블(reassemble) 할 수 있고, 리어셈블된 메시지를 수신 큐 (214b)에 놓는다. 원격 프로세스 (204)는 엘리먼트가 그것의 수신 큐 (214b)에 도달한 때 자동으로 통지 받을 수 있다. 원격 프로세스 (204)는 수신 큐 (214b)로부터 엘리먼트 (224)를 팝핑(pop)할 수 있고, 엘리먼트 (224)상에서 동작할 수 있고, 그런다음, 일부 경우들에서, 클라이언트 프로세스 (202)로 리턴될 응답을 생성할 수 있다. 원격 프로세스 (204)는 그것 자체의 발송 큐 (210b)에 응답을 함유하는 작업 큐 엘리먼트 (226)를 배치할 수 있다. 응답은 그런다음 로컬 시스템 (230)으로 다시 패브릭 (220)을 횡단할 수 있고, 여기서 그것은 “완료 큐 엔트리(completion queue entry)” (228) (흔히 CQE로 축약된)로서 클라이언트 프로세스 (202)에 전달된다.

정보의 이 교환에서, 로컬 시스템 (230) 및 원격 시스템 (232) 양쪽에서 운영 체제 커널은 거의 필요하지 않을 것이다. 예를 들어, 커널 바이패스를 구현하지 않은 시스템을 위한 경우와 같이, 클라이언트 프로세스 (202) 뿐만 아니라 원격 프로세스 (204)도 그것들의 개별 네트워크 어댑터 카드들의 사용을 중재하는 것이 필요하지 않을 수 있다. 대신에, 각각의 프로세스 (202,204)는 그것이 다른 프로세스 (202,204)와 배타적인 통신 채널을 갖는 것을 추정할 수 있다. 실제로, 다수의 프로세스들은 네트워크 패브릭 (220)를 통하여 통신하기 위해 네트워크 어댑터 카드들 (208a-b)을 이용할 수 있지만, 그러나 네트워크 어댑터 카드들 (208a-b)은 다수의 프로세스들과 그것들의 개별 큐 쌍들 사이의 중재를 관리한다. 추가적으로, 전송 계층 (216a-b)은 예컨대 예를 들어 발송 및 수신되고 및 어쩌면 네트워크 패브릭 (220)에 의해 드랍된 패킷들의 추적(track)을 유지하여 클라이언트 프로세스 (202)와 원격 프로세스 (204) 사이의 연결을 관리할 수 있다.

많은 구현예들에서, 전송 계층 (216a-b)은 발송 큐들 (212a-b)에 대한 몇몇 동작들을 지원할 수 있다. 예를 들어, 전송 계층 (216a-b)은 전형적인 발송 및 수신 동작들을 지원할 수 있고, 여기서 하나의 프로세스는 메시지를 제출하고 네트워크상의 다른 시스템상에 다른 프로세스는 해당 메시지를 수신한다. 다른 예로서, 전송 계층 (216a-b)은 RDMA-기록을 또한 지원할 수 있고, 여기서 하나의 프로세스는 원격 시스템의 메모리 버퍼에 직접 기록한다. 이 예에서, 원격 프로세스는 발송 시스템에 적절한 액세스 권한을 미리 줄 것이고, 원격 액세스에 대하여 등록된 메모리 버퍼들을 가질 것이다. 다른 예로서, 전송 계층 (216a-b)은 RDMA-판독을 지원할 수 있고, 여기서 하나의 프로세스는 원격 시스템의 메모리 버퍼로부터 직접 판독한다. 이 예에서, 원격 시스템은 또한 발송 시스템에 적절한 액세스 권한을 미리 줄 것이다. 다른 예로서, 전송 계층 (216a-b)은 RDMA-유형 원자 조작들을 또한 지원할 수 있다. 하나의 이런 원자 조작은 “비교 및 스왑(compare and swap)”이고 여기서 프로세스는 원격 메모리 위치를 판독하고, 만약 데이터 판독이 지정된 값이면, 동일한 원격 메모리 위치에 새로운 값을 기록한다. 다른 원자 조작은 “페치 추가(fetch add)”이고 여기서 프로세스는 원격 메모리 위치로부터 판독하고, 호출자(caller)에게 데이터 판독을 리턴하고, 그런다음 데이터에 지정된 값을 추가하고 변형된 값을 다시 동일한 원격 메모리 위치에 기록한다.

일부 구현예들에서, 전송 계층 (216a-b)은 수신 큐들 (214a-b)에 대한 동작들을 또한 지원할 수 있다. 예를 들어, 전송 계층 (216a-b)은 “포스트 수신 버퍼(post receive buffer)”로 불리우는 동작을 지원할 수 있고, 여기서 다른 시스템에 의해 개시된 발송, RDMA-기록, 및 RDMA-판독에 대한 타겟으로 사용될 수 있는 버퍼가 식별된다.

일부 구현예들에서, 큐 쌍이 개시된 때, 프로세스 개시는 큐 쌍을 전송 서비스 유형과 연관시킬 수 있다. 전송 서비스 유형은 그런 다음 어떻게 패킷들이 소스 시스템으로부터 목적지 시스템으로 송신되는지를 결정할 수 있다. 도 3은 전송 서비스 유형들(300)의 예들을 예시한다. VIA-유형 프로토콜들에 의해 사용되는 전송 서비스 유형들 (300)은 연결된 것(302) 또는 연결되지 않은 것(304), 및 신뢰할 수 있는 것(306) 또는 신뢰할 수 없는 것(308)으로 분류될 수 있다. 연결된 것(302) 및 연결되지 않은 것(304)은 발송 프로세스와 수신 프로세스 사이에 명백한 연결이 수립된지 여부를 설명한다. 연결된 (302) 전송 서비스 유형들 (300)로, 연결은 대부분의 구현예들에서, 발송과 수신 프로세스들에 배타적이다. 연결되지 않은 (304) 전송 서비스 유형들 (300)로, 패킷들 또는 “데이터그램들(datagrams)”이 네트워크로 발송되고, 전형적으로 그것들의 목적지로 이용가능한 어떤 경로들이든 따른다. 신뢰할 수 있는 것(306) 및 신뢰할 수 없는 것(308)은 전송 서비스 유형들 (300)이 패킷들의 전달을 보장하는지 여부를 설명한다. 신뢰할 수 있는 (306) 전송 서비스 유형들 (300)은 전형적으로 전달을 보장하지만, 그러나, 신뢰할 수 없는 (308) 전송 서비스 유형들 (300)은 전형적으로 보장하지 않는다.

연결된 (302), 신뢰할 수 있는 (306) 전송 서비스 유형 (300)의 예는 신뢰할 수 있는 연결 (310) (RC : Reliable Connection)라 불리운다. 신뢰할 수 있는 연결 (310)은 패킷들의 순서에 맞는(in-order) 전달을 보장한다. 순서에 맞다는 것은(in order) 메시지들이 그것들이 소스 애플리케이션에 의해 발송된 것과 동일한 순서로 목적지 애플리케이션에 전달된다는 것을 의미한다. 신뢰할 수 있는 연결 (310)은 통신 프로세스들의 각각의 쌍 사이의 연결의 명백한 수립을 추가로 요구한다. 명백한 연결(explicit connection)을 수립하기 위한 단계들의 예제는 아래와 같다: 클라이언트 프로세스는 목적지 시스템의 네트워크 어드레스를 룩 업(look up)하기 위해 통신 스택 (예를 들어, 도 2의 통신 스택 (200))을 먼저 사용할 수 있다. 클라이언트 프로세스는 다음으로 연결 컨텍스트를 생성하기 위해 전송 계층을 요청할 수 있다. 클라이언트 프로세스는 그런 다음 전송 계층 (또는 전송 관리)이 연결 컨텍스트를 원격 목적지 어드레스와 연관시키는 것을 요청할 수 있다. 마지막으로, 전송 계층 (또는 전송 관리)은 연결을 수립하기 위해 목적지 시스템과 메시지들의 교환 (예를 들어, “핸드쉐이크(handshake)”)를 수행할 수 있다.

도 3으로 돌아가서, 명백한 연결 수립은 신뢰할 수 있는 연결 (310) 유형 전송 서비스가 스케일링(scale) 하는 것을 어렵게 할 수 있다. 상기에서 언급한 바와 같이, 두개의 프로세스들이 네트워크를 가로질러 통신하기 위해, 명백한 연결이 수립되어야 한다. 따라서, 프로세스들이 네트워크에 연결된 노드에 추가될 때, 연결들의 수는 현저하게 증가한다. 예를 들어, 만약 로컬 시스템에서 100 프로세스들이 원격 시스템상에서 운용하는 전체 100 프로세스들과 통신할 것이면, 100 x 100 또는 10,000 연결들이 수립되어야 할 것이다. 더욱이, 컴퓨팅 클러스터는 수백 노드들을 가질 수 있고, 각각의 네트워크 노드는 수백 프로세서들 또는 그 이상을 실행시킬 수 있고, 잠재적으로 수천에 수천 연결들을 필요로 하는 클러스터로 귀결될 수 있다.

잠재적으로 더 확장할 수 있는 전송 서비스 유형 (300)은 신뢰할 수 없는 데이터그램 (316) (UD : Unreliable Datagram)이다. 신뢰할 수 없는 데이터그램 (316)은 명백한 연결 수립을 요구하지 않고, 전달을 보장하지 않는다. 전달을 보장하지 않는다는 것은 발신자(sender)가 패킷들을 네트워크 패브릭으로 송신하고, 패킷들이 그것들의 목적지에 도달하였는지 여부를 확인하기 위한 노력을 하지 않는다는 것을 의미한다. 신뢰할 수 없는 데이터그램 (316)은 관리 목적을 위한 메시지들, 예컨대 예를 들어 신뢰할 수 있는 연결 (310)을 수립하기 위해 교환되는 메시지들을 전송하기 위해 사용될 수 있다. 신뢰할 수 없는 데이터그램 (316)은 패킷 전달을 보장하지 않기 때문에, 그것은 패킷 드랍들이 빈번하지 않은 네트워크들 (예컨대 예를 들어 InfiniBand 네트워크들)에 효율적일 수 있다. 그러나, 패킷 드랍들이 있을 것 같은 네트워크들에서, 신뢰할 수 없는 데이터그램 (316)은 폭넓게 사용되지 않는다.

신뢰할 수 없는 연결 (312)은 패킷 드랍들이 있을 것 같은 네트워크들에 또한 사용될 수 있다. 신뢰할 수 있는 연결 (310)과 같이, 신뢰할 수 없는 연결 (312)은 명백한 연결 수립을 요구하지만, 그러나 전달을 보장하지 않는다. 신뢰할 수 없는 연결 (312)은 패킷 드랍들이 용인될 수 있는 애플리케이션들과 (예컨대 예를 들어 비디오 스트리밍을 위해) 사용될 수 있지만, 그러나 거의 드랍-용인(drop-tolerant)이 없는 애플리케이션들에 대하여는 문제가 있다.

신뢰할 수 있는 데이터그램 (314)(RD : Reliable Datagram)은 명백한 연결 수립을 요구하지 않고, 모든 패킷들의 전달을 보장한다. 신뢰할 수 있는 데이터그램 (314)은 원래는 신뢰할 수 있는 연결 (310)의 확장성 문제를 완화하기 위해 개발되었지만, 그러나 단일-연결 성능을 희생시켰다. 결과적으로, 신뢰할 수 있는 데이터그램 (314)은 폭넓게 사용되지 않는다.

몇몇의 전송 서비스 유형들 (300)이 주요 전송 서비스 유형들 (300)의 바람직한 측면들을 결합하려고 개발되었다. 확장된 신뢰할 수 있는 연결 (318) (XRC : Extended Reliable Connection )이 신뢰할 수 있는 연결의 (310) 확장성 문제를 다루기 위해 개발되었다. 확장된 신뢰할 수 있는 연결 (318)은 프로세스가 통신하는 목적지 시스템에서 모든 프로세스들에 대하여 목적지 시스템마다 단지 하나의 연결을 사용하는 것을 프로세스가 허용한다. 확장된 신뢰할 수 있는 연결 (318)은, 그러나, 복잡한 애플리케이션 인터페이스를 갖는 것으로 알려져 있다. 동적 연결된 것 (320) (DC : Dynamic Connected)는 신뢰할 수 있는 연결 (310)의 패킷 전달 보장을 신뢰할 수 없는 데이터그램 (316)의 명백한 연결 요건 없는 것과 결합하는 것을 시도한다. 동적 연결된 것 (320)으로, 신뢰할 수 있는 연결 (310)을 가진 경우처럼 연결들은 고정되지 않지만, 대신 필요한 때 셋업되고, 더 이상 필요하지 않은 때 제거된다. 동적 연결된 것(320)은, 그러나, InfiniBand-유형 네트워크들을 위하여 개발되었고, 여기서 패킷 드랍들은 매우 드물다. 동적 연결된 것(320)은 따라서 패킷 드랍들이 보다 빈번하게는 발생한 때 네트워크들에 효율성 부족을 겪을 수 있다.

이하의 섹션들에서 추가로 더 상세하게 설명되는 완화된 신뢰할 수 있는 데이터그램 (322) (RRD : Relaxed Reliable Datagram)은 패킷 드랍들이 드문 이벤트들이 아닌 네트워크들에서 확장성 및 보장된 패킷 전달을 제공할 수 있다. 완화된 신뢰할 수 있는 데이터그램 (322)은 신뢰할 수 없는 데이터그램 (316)에 유사한 간단한, 무접속 인터페이스를 유저 애플리케이션에 제공할 수 있다. 완화된 신뢰할 수 있는 데이터그램 (322)은 또한 신뢰할 수 있는 연결 (310)에 유사하게 패킷 전달을 보장하다. 완화된 신뢰할 수 있는 데이터그램 (322)은 패킷들을 순서에 맞게 전달하지 않고, 그렇게 함으로써 전송 디자인을 간략화하고 잠재적으로 패킷 전달의 효율을 증가시킨다.

도 4 는 상기에서 설명된 하나 이상의 전송 서비스들에 추가하여, 완화된 신뢰할 수 있는 데이터그램 전송(Relaxed Reliable Datagram transport)를 지원하도록 구성될 수 있는 시스템(400)의 예를 예시한다. 하드웨어 및 소프트웨어 컴포넌트들의 면에서 설명되지만, 예제 시스템 (400)은 주로 기능적인 설명이고, 예시된 다양한 컴포넌트들은 이 특정 예제에서 설명된 것들 외에 하드웨어, 소프트웨어, 하드웨어 및 소프트웨어의 조합으로, 및 로직 및/또는 물리적 구성들로 구현될 수 있다.

예제 시스템 (400)은 호스트 디바이스 (410) 및 네트워크 어댑터 디바이스 (420)를 포함한다. 호스트 디바이스 (410) 및 네트워크 어댑터 디바이스 (420)는 물리적 연결, 예컨대 케이블, 플러그, 소켓, 슬롯, 인쇄 회로 기판, 또는 이들 물리적 컴포넌트들의 조합을 통하여 통신상태에 있을 수 있다. 호스트 디바이스 (410)는 본 출원에 예시되지 않은 컴포넌트들 예컨대 하나 이상의 프로세서들, 메모리 서브시스템들, 주변 디바이스들, 등등을 포함하는 범용 컴퓨팅 시스템일 수 있다. 일부 구현예들에서, 이하에 설명되는 네트워크 어댑터 디바이스 (420)의 동작들은 집적 회로 디바이스, 및/또는 집적 회로 디바이스의 집합으로 구현될 수 있다. 예를 들어, 다양한 구현예들에서, 네트워크 어댑터 디바이스의 동작은 SoC(system-on-a-chip), FPGA(field-programmable gate array), 또는 ASIC(application-specific integrated circuit), 또는 이들 디바이스들의 조합으로 구현될 수 있다.

호스트 디바이스 (410)는 하나 이상의 가상 기계들 (402)을 실행시키도록 구성될 수 있다. 가상 기계(virtual machine)는 실제 또는 가상 컴퓨팅 시스템을 나타내는 어뮬레이트(emulated) 컴퓨팅 환경이다. 가상 기계는 물리적 컴퓨터에 유사하게 운영 체제를 포함한 프로그램들을 실행시킬 수 있다. 가상 기계들은 일반적으로 서로로부터 격리되어 동작하고, 가상 기계내 프로세스는 상이한 가상 기계에서 운용하는 프로세스들에 영향을 미칠 수 없다. 가상 기계들은 전문화된 하드웨어, 소프트웨어 및 하드웨어 및 소프트웨어의 조합을 수반할 수 있다.

예제 시스템 (400)의 가상 기계 (402)는 하나 이상의 유저 애플리케이션들 (404a-b)을 실행시키는 것일 수 있다. 유저 애플리케이션들 (404a-b)은 예를 들어, 고성능 컴퓨팅 애플리케이션들, 다른 계산 집약적인 프로그램들, 및 보통의 유저 애플리케이션들, 예컨대 예를 들어 문서 편집 툴들 및 웹 브라우저들을 포함한다. 대부분의 구현예들에서, 유저 애플리케이션들 (404a-b)은 “유저 스페이스(user space)”에서 즉, 그것들이 서로로부터, 운영 체제(전형적으로 “커널 스페이스(kernel space)”에서 운용하는)로부터, 및 하지의(underlying) 하드웨어로부터 격리된 환경에서 운용한다. 운영 체제 커널 (412)은 각각의 유저 애플리케이션들 (404a-b) 및 하지의 하드웨어에 대한 액세스를 포함하여 더 많은 액세스 권한을 가질 수 있다.

유저 애플리케이션들 (404a-b)은 표준 라이브러리 (406) 및/또는 유저-스페이스 드라이버 프로그램 (408)을 통하여 시스템 (400) 하드웨어와 통신할 수 있다. 표준 라이브러리 (406)는 흔한 동작들을 실행시키기 위해 잘 이해되고 동의된 API(Application Programming Interface)을 제공한다. 이들 흔한 동작들은 예를 들어, 빈번하게는 실행되는 소프트웨어 동작들 및 시스템의 (400) 하드웨어에 대한 액세스를 포함할 수 있다. 표준 라이브러리들의 하나의 카테고리는 커널-바이패스 프레임워크들을 위해 정의된 것들이다. 이들 라이브러리들은 예를 들어, OFA(OpenFabrics Alliance) OFED(Open Fabrics Distribution) 버브(verbs) 라이브러리 및 OFI(LibFabric OpenFabrics Interfaces), OpenFabrics 인터페이스들을 구현하는 오픈 소스 리눅스 라이브러리를 포함한다. OFED는 원래 InfiniBand 버브에 API를 제공하기 위해 개발되었다. InfiniBand 버브는 임의의 하드웨어 또는 운영 체제와 무관한 InfiniBand 어댑터의 기능의 개요 설명이다. OFED는 나중에 비-InfiniBand 어댑터들을 지원하도록 진화한다. OFED API의 시맨틱(semantics)은, 그러나, 일반적으로 많은 애플리케이션들의 요건들과 호환 불가능하고, 특별히 더 큰 스케일들에서 사용하기가 어려운 것으로 알려져 있다. OFI는, 그에 반해서, 다수의 유형들의 시맨틱을 제공하고, 하지의 하드웨어 성능들을 노출시키는 것에 추가하여 애플리케이션 요구들에 초점을 맞춘 것으로 알려져 있다.

일부 구현예들에서, 표준 라이브러리 (406)는 유저-스페이스 드라이버 프로그램 (408)과 통신 상태에 있을 수 있고, 여기서 유저-스페이스 드라이버 프로그램 (408)은 특정 하드웨어 디바이스에 대한 액세스를 제공하도록 구성된다. 일부 경우들에서, 유저 애플리케이션 (404b)은 직접 유저-스페이스 드라이버 프로그램 (408)과 직접 통신할 수 있다. 이 예에서, 유저-스페이스 드라이버 프로그램 (408)은 네트워크 어댑터 디바이스 (420)에 대한 액세스를 제공할 수 있다. 유저-스페이스 드라이버 프로그램 (408)은 표준 라이브러리 (406)에 의해 제공된 추상적 개념과 네트워크 어댑터 디바이스 (420)의 특정 하드웨어간의 인터페이스를 제공할 수 있다. 예를 들어, 유저-스페이스 드라이버 프로그램 (408)은 일부 구현예들에서 네트워크 어댑터 디바이스 (420)에 위치될 수 있는 발송 및 수신 큐들을 포함하여 통신 스택에 대한 액세스를 제공할 수 있다.

일부 구현예들에서, 유저 애플리케이션들 (404a-b)은 구성 동작들을 위해 운영 체제 커널 (412)과 통신할 수 있다. 예를 들어, 유저 애플리케이션들 (404a-b)은 가상 어드레스들 및 메모리 영역들을 커널 (412)에 등록할 수 있다. 일부 구현예들에서, 커널 (412)은 커널-스페이스 전송 드라이버 (416)를 포함할 수 있다. 커널-스페이스 전송 드라이버 (416)는 유저 애플리케이션들 (404a-b), 메모리 등록, 및 네트워크 어드레스 관리에 큐 쌍들의 매핑을 포함하는 제어 동작들을 실행시키도록 구성될 수 있다.

네트워크 어댑터 디바이스 (420)는 네트워크 (430)와 통신하도록 구성될 수 있다. 네트워크 어댑터 디바이스 (420)는 발송 및 수신 동작들을 실행시키도록 구성될 수 있는 관리 모듈 (422)을 가질 수 있다. 관리 모듈 (422)은 예를 들어, 펌웨어 또는 집적 회로, 예컨대 FPGA 또는 ASIC일 수 있다. 네트워크 (430)를 통하여 메시지들을 발송하기 위해서, 관리 모듈 (422)은 유저 애플리케이션의 메시지를 이용하여 패킷들을 생성하고 패킷 헤더들을 빌드(build)하도록 구성될 수 있다. 네트워크 (430)로부터 메시지들을 수신하기 위해서, 관리 모듈 (422)은 패킷 헤더들을 제거하고 수신된 메시지를 수신 유저 애플리케이션 (404a-b)쪽으로 송신하도록 구성될 수 있다. 수신된 메시지는 일부 경우들에서, 발신자의 어드레스, 또는 발신자를 식별하는 일부 다른 정보를 포함한다.

네트워크 어댑터 디바이스 (420)는 하나 이상의 전송 서비스들, 예컨대 예를 들어 신뢰할 수 없는 데이터그램 전송 (424) 및 완화된 신뢰할 수 있는 데이터그램 전송 (426)을 제공할 수 있다. 네트워크 어댑터 디바이스 (420)는 본 출원에 예시되지 않은 다른 전송 서비스들을 제공할 수 있다. 일부 구현예들에서, 완화된 신뢰할 수 있는 데이터그램 전송 (426)은 신뢰할 수 있는 연결-유형 행위(Reliable Connection-type behavior)를 제공하도록 구성될 수 있다. 이들 구현예들에서, 완화된 신뢰할 수 있는 데이터그램 컨텍스트가 단일 큐 쌍에 할당될 수 있고, 하나의 로컬 유저 애플리케이션과 하나의 원격 유저 애플리케이션 사이에 하나의 통신 채널에 독점(exclusive) 전송 컨텍스트를 만든다.

상기에서 언급한 바와 같이, 완화된 신뢰할 수 있는 데이터그램 전송 (426)을 이용하는 메시지 전송은 “무접속(connectionless)” 일 수 있고, 즉, 유저 애플리케이션들이 타겟 애플리케이션과 명백한 연결을 수립하는 것을 필요로 하지 않을 수 있다. 대신에, 연결 관리는 완화된 신뢰할 수 있는 데이터그램 전송 (426)에 의해 핸들링될 수 있다.

추가적으로, 완화된 신뢰할 수 있는 데이터그램 전송 (426)은 패킷들의 전달을 보장할 수 있고, 이는 그것들의 목적지에 순서가 바뀌어서 도달할 수 있다. 이것은 패킷들이 그것들이 소스 시스템에서 발원된 때와 동일한 시퀀스로 그것들을 놓는 재순서화되는 것이 필요로 할 수 있다는 것을 의미할 수 있다. 전통적으로, 패킷 순서화 및 신뢰성 동작들은 네트워크 어댑터에서 또는 호스트 디바이스 소프트웨어에서 함께 핸들링되었다. 예를 들어, 패킷 전달을 보장하는 가장 신뢰할 수 있는 전송 서비스 유형들은 전형적으로 패킷들을 드랍하지 않는 네트워크에 의존하다. 드랍된 패킷들은 순서가 바뀌어서 (하나 이상의 패킷들이 도달되지 않기 때문에) 도달하는 패킷들로 귀결될 수 있고, 이 경우에 네트워크 어댑터 디바이스는 순서가 바뀐 패킷들을 거부(reject)할 수 있고, 또는 패킷들의 전체 스트림이 재발송되는 것을 요구할 수 있다.

다른 대안은 네트워크 어댑터 디바이스가 순서가 바뀌어서 도달된 패킷들을 재순서화(re-order)할 것이다. 패킷 재순서화는, 그러나, 일반적으로 프로세싱 집약(intensive) 동작이다. 네트워크 어댑터 디바이스들은 전형적으로 값이 싸고 덜 강력한 프로세서들을 가진다. 따라서, 순서가 바뀐 패킷들을 처리하기 위해 시도하는 구현예들은 일반적으로 호스트 디바이스 소프트웨어에서 패킷들을 재순서화하고, 일반적으로 호스트 디바이스에 의해 제공된 더 강력한 프로세서들을 이용한다. 이들 구현예들에서, 소프트웨어는 또한 동작들 예컨대 추적(tracking) 및 누락 패킷들 재요청을 포함하여 신뢰할 수 있는 패킷 전달을 보장하는 것을 시도하였다. 상기에서 논의된 바와 같이, 그러나, 프로세서 개입은 레이턴시에 부정적으로 영향을 미칠 수 있다. 따라서 신뢰할 수 있는 패킷 전달을 추구하는 구현예들은 네트워크 어댑터 디바이스내 신뢰성 측면들을 구현하였고 결과적으로, 패킷들의 순서가 맞는(in-order) 전달을 요구하였다.

완화된 신뢰할 수 있는 데이터그램 전송을 이용하는 시스템들, 예컨대 도 4의 예제 시스템 (400)은 패킷 재순서화 및 신뢰성 동작들을 분리할 수 있고, 그것들이 가장 효율적으로 핸들링될 수 있는 시스템내 지점들에서 그것들을 실행할 수 있다. 예를 들어, 시스템 (400)은 패킷들의 신뢰할 수 있는 전달은 네트워크 어댑터 디바이스 (420)에 의해 핸들링되도록 구성될 수 있고, 이는 네트워크 (430)를 걸쳐 패키들을 전송할 때 고유의 레이턴시를 최소화하기 위해 더 적합하게될 수 있다. 더욱이, 패킷 재순서화는 유저 애플리케이션 (404a-b) 및/또는 드라이버 프로그램 (408,416)에 의해 핸들링될 수 있고, 각각은 호스트 디바이스의 (410) 프로세서상에 실행될 수 있다.

어떻게 신뢰할 수 있는, 순서가 바뀐 패킷 전달이 성취될 수 있는 지를 설명하기 전에, 연결 수립이 먼저 설명된다. 완화된 신뢰할 수 있는 데이터그램 전송을 이용하는 시스템들에서, 전송 서비스는 컴퓨팅 클러스터에 의해 제공된 네트워크를 가로질러 서로와 통신하는 유저 애플리케이션들에 대한 "무접속" 메시지 전송이 가능하게 할 수 있다.

I. “무접속” 메시지 전송 ("CONNECTIONLESS" MESSAGE TRANSFER)

도면들 5a-5b는 유저 애플리케이션(504a)이 나중에 메시지들을 다른 애플리케이션에 송신하기 위해 사용할 수 있는 어드레스 핸들을 유저 애플리케이션(504a)이 획득할 수 있는 프로세스(500)의 예를 예시한다. 프로세스 (500)는 명백한 연결이 유저 애플리케이션 (504a)에 의해 수립되지 않는다는 점에서 신뢰할 수 있는 데이터그램 및 신뢰할 수 없는 데이터그램 전송들에 의해 사용되는 프로세스들에 유사할 수 있다. 프로세스 (500)는 전송 서비스 (여기서, 완화된 신뢰할 수 있는 데이터그램 전송)는 다른 시스템들로의 연결을 수립하고 유지하는데 책임이 있을 수 있다는 점에서 신뢰할 수 있는 데이터그램 및 신뢰할 수 없는 데이터그램에 의해 사용되는 것들과 상이할 수 있다. 더욱이, 이 연결 유지보수는 유저 애플리케이션들로부터 숨겨지고, 이는 명백한 연결들 대신에 어드레스 핸들들에 제공된다. 유저 애플리케이션 (504a)은 유저 애플리케이션이 통신할 각각의 목적지에 대한 어드레스 핸들을 획득하기 위해 동일한 프로세스 (500)를 사용할 수 있다. 도 5a는 목적지가 호스트 디바이스 (502)상에서 실행하는 임의의 프로세스에 의해 미리 등록되지 않는 때 프로세스 (500)의 부분을 예시한다. 도 5b는 목적지가 미리 등록된 경우를 예시한다.

일부 구현예들에서, 유저 애플리케이션 (504a)은 네트워크를 통하여 메시지들을 발송하기 위해 어드레스 핸들들을 사용하지 않을 수 있다. 예를 들어, 유저 애플리케이션 (504a)은 메시지들을 송신하기 위해 목적지 어드레스, 또는 일부 다른 목적지 정보를 사용할 수 있다. 이들 경우들에서, 유저 애플리케이션 (504a)은 어드레스 핸들을 제공하는 대신에 네트워크 어댑터 디바이스에 목적지 정보를 직접 제공할 수 있다. 이들 구현예들에서, 도면들 5a-5b에 예시된 프로세스 (500)는 적어도 일부 목적지들에 대하여 유저 애플리케이션 (504a)에 의해 사용되지 않을 수 있다. 유저 애플리케이션이 메시지들을 송신하기 위해 어드레스 핸들(address handle)외에 목적지 정보를 사용하는 경우들이 도면들 6a-6b에 대하여 추가로 설명된다.

도 5a에 예시된, 프로세스 (500)는 네트워크 어댑터 디바이스 (520)와 통신하는 호스트 디바이스 (502)를 수반할 수 있다. 호스트 디바이스 (502)는 본 출원에 예시되지 않은 컴포넌트들 예컨대 하나 이상의 프로세서들, 메모리 서브시스템들, 주변 디바이스들, 등등을 포함하는 범용 컴퓨팅 시스템일 수 있다. 호스트 디바이스 (502)는 예시된 유저 애플리케이션 (504a)를 포함하여 하나 이상의 유저 애플리케이션들을 실행시킬 수 있다. 이들 유저 애플리케이션들은 본 출원에 예시되지 않은 하나 이상의 가상 기계들에서 운용될 수 있다. 호스트 디바이스 (502)는 예시된 드라이버 프로그램 (508)을 포함하여 하나 이상의 드라이버 프로그램들을 또한 실행시키실 수 있다. 드라이버 프로그램 (508)은 운영 체제 커널내에서 실행될 수 있다. 커널내 동작은 물리적 메모리 및 호스트 디바이스의 하드웨어에 대한 액세스를 포함하여 드라이버 프로그램에 더 많은 액세스 권한들을 제공할 수 있다. 대안적으로 또는 추가적으로, 드라이버 프로그램 (508)은 유저 스페이스에서 실행될 수 있고, 여기서 그것은 더 적은 액세스 권한들을 가질 수 있고, 덜 안전할 수 있다.

네트워크 어댑터 디바이스 (520)는 네트워크와 통신하기 위한 범용 네트워크 인터페이스 카드일 수 있다. 대안적으로 또는 추가적으로, 네트워크 어댑터 디바이스 (520)는 특정 유형의 네트워크 (예를 들어, InfiniBand 네트워크)와 통신하기 위한 특정한 목적의 카드일 수 있다. 네트워크 어댑터 디바이스 (520)는 관리 모듈 (522)을 포함할 수 있다. 관리 모듈 (522)은 예를 들어, 펌웨어 또는 집적 회로, 예컨대 FPGA 또는 ASIC일 수 있다. 네트워크 어댑터 디바이스 (520)는 네트워크 어댑터 디바이스 (520)의 동작과 관련된 데이터를 저장하기 위한 메모리를 또한 포함할 수 있다. 대안적으로 또는 추가적으로, 메모리는 관리 모듈 (522)에 통합될 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (520)는 RDMA-유형 기능 (즉, 커널 바이패스 기능)을 포함할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (520)는 PCI(Peripheral Component Interconnect) 유형 디바이스이고, PCI 버스를 통하여 호스트 디바이스 (520)와 통신한다. 일부 구현예들에서, 이하에 설명되는 네트워크 어댑터 디바이스 (420)의 동작들은 집적 회로 디바이스, 또는 집적 회로 디바이스의 집합으로 구현될 수 있다. 예를 들어, 다양한 구현예들에서, 네트워크 어댑터 디바이스의 동작은SoC, FPGA, 또는 ASIC, 또는 이들 디바이스들의 조합에서 구현될 수 있다.

목적지 노드와 통신하기 위해 어드레스 핸들을 획득하기 위해, 유저 애플리케이션 (504a)은 먼저 목적지의 어드레스를 결정한다. 목적지는 대부분의 경우들에서, 네트워크에 연결된 다른 시스템상에서 실행하는 애플리케이션이다. 목적지의 어드레스는 예컨대 네트워크상에 시스템의 IP(Internet Protocol) 또는 MAC(Media Access Control) 어드레스일 수 있다. 대안적으로 또는 추가적으로, 목적지 어드레스는 특정 타겟 애플리케이션을 식별하는 어드레스와 같이 특정될 수 있다. 대안적으로 또는 추가적으로, 목적지 어드레스는 일반(general)과 특정(specific) 사이에 해당할 수 있다.

유저 애플리케이션 (504a)은 표준 메커니즘들을 이용하여 목적지 어드레스를 획득할 수 있고, 예를 들어, 일부 구현예들에서, 유저 애플리케이션 (504a)은 유저-제공된 입력로부터, 및/또는 표준 어드레스 분해 메커니즘들(standard address resolution mechanism)에 의해 목적지 어드레스를 획득할 수 있고, 예컨대 DNS(domain name system) 서버에 의해 제공된다. 일부 구현예들에서, 유저 애플리케이션 (504a)은 타겟 애플리케이션과 메시지들을 교환함으로써 목적지 어드레스를 획득할 수 있다. 예를 들어, 유저 애플리케이션 (504a)은 네트워크상에서 운용하는 표준 소켓 시스템을 사용할 수 있고, 그것 자체의 어드레스르 타겟 애플리케이션의 어드레스와 교환할 수 있다. 다른 예로서, 유저 애플리케이션 (504a)은 이 정보를 교환하기 위해서 지정된 또는 특별한 목적을 위해 만들어진(purpose-built) 사이드밴드 네트워크를 사용할 수 있다. 일부 구현예들에서, 유저 애플리케이션 (504a)은 목적지 어드레스를 해결하는 방식은 특정 애플리케이션에 특정된다.

목적지 어드레스가 결정되면, 유저 애플리케이션 (504a)은 어드레스 핸들을 위해 드라이버 프로그램 (508)에 요청 (550)을 제출할 수 있다. 이 요청(550)은 적어도 목적지 어드레스를 포함할 수 있다. 일부 구현예들에서, 드라이버 프로그램 (508)은 커널 드라이버 프로그램이고, 이는 호스트 디바이스 (502)상에서 실행하는 모든 프로세서들에 대한 어드레스 핸들들을 중점적으로 관리하도록 구성될 수 있다. 다른 구현예들에서, 드라이버 프로그램 (508)은 일반적으로 디바이스 드라이버들에 이용 가능한 표준 액세스 권한들을 갖는 유저-스페이스 디바이스 드라이버이다. 일부 구현예들에서, 요청 (550)은 먼저 디바이스 드라이버로 가고 그런 다음 커널 드라이버로 간다. 다른 구현예들에서, 요청 (550)은 유저 애플리케이션 (504a)으로부터 커널 드라이버로 직접 갈 수 있다.

드라이버 프로그램 (508)은 단계 (552)에서, 어드레스 핸들 요청 (550)내 목적지 어드레스가 “새로운 것(new)” 인지 여부; 즉, 드라이버 프로그램 (508)이 이 목적지 어드레스를 미리 등록하였는지 여부를 결정할 수 있다. 드라이버 프로그램 (508)은 호스트 디바이스 (502)상에서 실행하는 프로세스들에 의해 현재 사용중인 목적지 어드레스들의 리스트 또는 디렉토리, 통상 소위 “어드레스 맵(address map)” (514)을 유지할 수 있다. 일부 구현예들에서, 어드레스 맵 (514)은 네트워크 어댑터 디바이스 (520)에 의해 유지될 수 있다. 어드레스 핸들 요청 (550) 수신시, 드라이버 프로그램 (508)은 만약 그것이 목적지 어드레스를 함유하는지를 알기 위해 어드레스 맵 (514)을 조사할 수 있다. 도 5a의 예에서, 드라이버 프로그램 (508)은 어드레스 맵 (514)에서 목적지 어드레스를 발견할 수 없고, 따라서 목적지 어드레스가 새롭다고 결정한다.

목적지 어드레스가 새롭다고 결정하면, 드라이버 프로그램 (508)은 새로운 어드레스 핸들을 위해 네트워크 어댑터 디바이스 (520)상에서 실행하는 관리 모듈 (522)에 요청 (554)을 배치할 수 있다. 이 새로운 어드레스 핸들 요청 (554)은 목적지 어드레스를 포함할 수 있다. 관리 모듈 (522)은 예컨대 예를 들어 유저 애플리케이션 (504a) (또는 유저 애플리케이션 (504a)이 실행되는 가상 기계)이 타겟 애플리케이션이 발견될 수 있는 시스템과 통신하도록 허용되는지를 확인하여 목적지 어드레스에 대한 체크를 실행할 수 있다. 관리 모듈 (522)은 그런 다음 네트워크 어댑터 디바이스 (520)상의 메모리 (528)에 목적지 어드레스를 저장할 수 있다.

일부 구현예들에서, 관리 모듈 (522)은 메모리 (528)에 네트워크 어드레스 맵 객체(network address map object) (556)를 저장할 수 있다. 네트워크 어드레스 맵 객체는 목적지 어드레스에 관련된 정보를 저장할 수 있는 데이터 구조의 인스턴스이다. 예를 들어, 네트워크 어드레스 맵 객체 (556)는 목적지 어드레스를 포함할 수 있다. 일부 구현예들에서, 네트워크 어드레스 맵 객체 (556)는 관리 모듈 (522)에 의해 생성된 미리-생성된 패킷 헤더를 포함할 수 있다. 미리-생성된 패킷 헤더는 소스 및 목적지 어드레스들, 및/또는 목적지 시스템으로 네트워크를 횡단하기위해 패킷에 요구될 수 있는 다른 라우팅 정보, 및/또는 다른 헤더 정보를 포함할 수 있다. 미리-생성된 패킷 헤더는 나중에 사용하기 위해 저장될 수 있어서 빠르게 패킷들을 형성한다. 일부 구현예들에서, 네트워크 어드레스 맵 객체는 미리-생성된 내부 및 외부 헤더들을 포함할 수 있다. 내부 및 외부 헤더들은 하나의 프로토콜에 따라 생성된 패킷이 다른 프로토콜을 위해 의도된 헤더들에 엔캡슐레이트(encapsulate)될 때 사용될 수 있다. 인캡슐레이션은 즉, 상이한 네트워크 프로토콜을 위해 구성된 네트워크상에서 하나의 프로토콜에 따라 구성된 패킷들을 송신하는 네트워크 터널링(network tunneling)에서 발생할 수 있다. 패킷을 엔캡슐레이트하여 외부 헤더를 제공함으로써, 내부 헤더는 외부 네트워크 프로토콜을 수용하기 위해 변형될 필요가 없다. 미리-생성된 내부 및 외부 헤더들은 네트워크 어드레스 맵 객체와 함께 저장될 수 있다.

목적지 어드레스가 새롭기 때문에, 관리 모듈은 추가적으로 또는 대안적으로, 전송 컨텍스트(transport context) (524)를 구성할 수 있다. 전송 컨텍스트 (524)는 목적지 어드레스와 관련된 시스템과 연결을 수립하고 유지한다. 전송 컨텍스트는 네트워크에 연결된 각각의 가능한 목적지 시스템에 대해 구성될 수 있지만, 그러나 일반적으로 전송 컨텍스트는 그것이 요구될 때까지 구성되지 않는다. 전송 컨텍스트들은, 대부분의 구현예들에서, 두개의 애플리케이션들 간에 또는 애플리케이션과 시스템 간에 보다는 두개의 시스템들간에 연결을 설명한다. 전송 컨텍스트 (524)를 구성하는 것은 목적지 시스템과 연결을 수립하는 것을 포함할 수 있다. 이 연결은 예를 들어, 네트워크 어댑터 디바이스 (520)와 목적지 시스템 간에 메시지들의 교환에 의해 수립될 수 있다. 일단 구성된 후에, 전송 컨텍스트 (524)는 연결의 상태를 유지 및 모니터링할 수 있다. 연결의 유지보수는 무엇보다도, 목적지 시스템과 관련된 네트워크 어드레스 맵 객체들의 저장 또는 그렇지 않으면 그것들의 추적 유지를 포함할 수 있다. 상기에서 언급한 바와 같이, 목적지 어드레스는 목적지 시스템의 어드레스보다 더 특정될 수 있고, 그래서 하나 초과의 네트워크 어드레스 맵 객체가 소정의 전송 컨텍스트에 대하여 존재할 수 있다. 전송 컨텍스트 (524)는 전송 서비스 유형, 예컨대 신뢰할 수 없는 데이터그램 또는 완화된 신뢰할 수 있는 데이터그램에 할당될 수 있다. 전송 컨텍스트들은 이하에 보다 상세하게 설명된다.

목적지 어드레스 또는 네트워크 어드레스 맵 객체 (556)를 저장하고, 및/또는 전송 컨텍스트 (524)를 구성하면, 관리 모듈 (522)은 그 다음에 드라이버 프로그램 (508)에 어드레스 핸들 (558)을 리턴할 수 있다. 어드레스 핸들 (558)은 네트워크 어댑터 디바이스의 (520) 메모리 (528)에 저장된 목적지 어드레스 또는 네트워크 어드레스 맵 객체 (556)와 관련된 기준(reference), 포인터(pointer), 및/또는 인덱스(index)일 수 있다. 드라이버 프로그램 (508)은 그것의 어드레스 맵 (514)에 어드레스 핸들 (558)을 저장할 수 있고, 여기서 그것은 목적지 어드레스에 의해 발견될 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (520)는 어드레스 맵 (514)을 관리할 수 있고, 이 경우에 관리 모듈 (522)은 어드레스 맵 (514)에 어드레스 핸들을 저장할 수 있다. 목적지 어드레스는 이제 “등록된 것(registered)”으로 간주될 수 있는데 왜냐하면 드라이버 프로그램 (508)이 그것을 알게 되었기 때문이다. 드라이버 프로그램 (508)은 그런다음 어드레스 핸들 (558)을 유저 애플리케이션 (504a)으로 발송할 수 있다. 유저 애플리케이션 (504a)은 대부분의 경우들에서, 나중 사용을 위해 어드레스 핸들 (558)를 저장할 수 있거나 또는 다른 식으로 유지할 수 있다.

앞에서 언급된 바와 같이, 도 5a는 유저 애플리케이션 (504a)이 드라이버 프로그램 (508)에 아직 등록되지 않은 목적지에 대한 어드레스 핸들을 요청한 경우를 예시한다. 도 5b는 유저 애플리케이션 (504b)이 드라이버 프로그램 (508)에 이미 등록된 목적지에 대한 어드레스 핸들을 요청한 예를 예시한다. 도 5a에서처럼, 도 5b에서 유저 애플리케이션 (504b)은 유저 애플리케이션 (504b)이 통신할 목적지에 대한 목적지 어드레스를 먼저 결정할 수 있다. 유저 애플리케이션 (504b)은 도 5a에 예시된 것과 동일한 유저 애플리케이션 (504a)일 수 있거나, 또는 동일한 호스트 디바이스 (502)상에서 실행하는 상이한 유저 애플리케이션일 수 있다.

도 5b로 돌아가서, 목적지 어드레스가 결정되면, 유저 애플리케이션 (504b)은 어드레스 핸들을 위해 드라이버 프로그램 (508)에 요청 (550)을 제출할 수 있다. 이 예에서, 드라이버 프로그램 (508)은 단계 (552)에서, 요청 (550)과 함께 발송된 목적지 어드레스를 조사할 수 있고, 목적지 어드레스가 어드레스 맵 (514)에서 발견될 수 있는지를 결정할 수 있다. 이것은 목적지 어드레스가 드라이버 프로그램 (508)에 이미 등록되었다는 것을 의미한다. 이것은 또한 네트워크 어댑터 디바이스 (520)가 도 5a에 경우에서처럼 어드레스 핸들을 제공하기 위해 액세스될 필요가 없다는 것을 의미할 수 있다. 일부 구현예들에서, 어드레스 맵 (514)은 네트워크 어댑터 디바이스 (520)에 의해 유지되고, 이 경우에 드라이버 프로그램 (508)은 목적지 어드레스를 룩 업하기 위해 네트워크 어드레스 맵 (520)에 문의할 수 있다. 이들 구현예들에서, 네트워크 어댑터 디바이스 (520)는 목적지 어드레스가 미리 등록되었는지, 어드레스 핸들 (558)을 드라이버 프로그램 (508)에 제공하는지를 결정할 수 있다.

도 5b에서, 목적지 어드레스가 미리 등록되었다고 결장하면, 그러면 드라이버 프로그램 (508)은 어드레스 맵 (514)에 저장된 정보를 이용하여 어드레스 핸들 (558)을 제공할 수 있다. 예를 들어, 어드레스 맵 (514)은 기준, 포인터, 및/또는 인덱스를 저장할 수 있고, 드라이버 프로그램 (508)은 저장된 기준, 포인터, 또는 인덱스를 나타내는 새로운 어드레스 핸들 (558)을 생성할 수 있다. 어드레스 핸들 (558)은 나중 사용을 위해 어드레스 핸들 (558)을 저장할 수 있는 유저 애플리케이션 (504b)으로 리턴될 수 있다.

도면들 6a-6b는 유저 애플리케이션(604)이 메시지를 송신하기 위해 도면들 5a-5b에 따라 획득된 어드레스 핸들(658)을 사용할 수 있는 프로세스(600)의 예를 예시한다. 일부 구현예들에서, 유저 애플리케이션 (604)은 어드레스 핸들 (658)을 사용하지 않을 수 있고, 대신 메시지를 송신하기 위해 다른 목적지 정보를 사용할 수 있다. 이들 구현예들은 이하에서 보다 상세하게 설명될 것이다.

도면들 6a-6b에서, 프로세스 (600)는 호스트 디바이스 (602) 및 네트워크 어댑터 디바이스 (620)를 수반할 수 있다. 호스트 디바이스 (602)는 본 출원에 예시되지 않은 컴포넌트들 예컨대 하나 이상의 프로세서들, 메모리 서브시스템들, 주변 디바이스들, 등등을 포함하는 범용 컴퓨팅 시스템일 수 있다. 호스트 디바이스 (602)는 예시된 유저 애플리케이션 (604)를 포함하여 하나 이상의 유저 애플리케이션들을 실행시킬 수 있다. 네트워크 어댑터 디바이스 (620)는 네트워크(630)와 통신하기 위한 범용 네트워크 인터페이스 카드일 수 있고 및/또는 특정 유형의 네트워크와 통신하기 위한 특정 목적 카드일 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스의 동작들은 집적 회로 디바이스, 및/또는 집적 회로 디바이스의 조합으로 구현될 수 있다. 네트워크 어댑터 디바이스 (620)는 메모리 (628)를 또한 포함할 수 있지만, 그러나 일부 구현예들에서 메모리 (628)는 네트워크 어댑터 디바이스 (620) 상에 인스톨된 펌웨어(예시되지 않은)로 통합된다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (620)는 메모리를 가지지 않을 수 있거나 정보를 저장하기 위해 단지 작은 양의 메모리를 가질 수 있고, 호스트 디바이스 (602)상에 메모리를 사용할 수 있다.

도 6a에서, 유저 애플리케이션 (604)은 네트워크상에 상이한 시스템상에서 운용하는 다른 애플리케이션으로 발송되도록 의도된 메시지(660)를 가질 수 있다. 이 예에서, 유저 애플리케이션 (604)은 타겟 애플리케이션과 관련된 어드레스 핸들 (658)을 미리 획득하였다. 메시지 (660)를 타겟 애플리케이션에 송신하기 위해, 유저 애플리케이션 (604)은 네트워크 어댑터 디바이스 (620)에 어드레스 핸들 (658)과 함께 메시지 (660)를 발송할 수 있다. 일부 구현예들에서, 메시지 (660)는 네트워크 어댑터 디바이스 (620)로 송신되기 전에 디바이스 드라이버로 먼저 송신될 수 있다.

메시지 (660)를 수신한 후에, 네트워크 어댑터 디바이스 (620)는 메시지 (660)에 대한 전송 컨텍스트 (624)를 결정하기 위해 어드레스 핸들을 사용할 수 있다. 전송 컨텍스트 (624)는 일반적으로 메시지 (660)를 수신할 시스템과 연결을 유지한다. 연결을 유지하는 것은 예를 들어, 패킷들 송신, 아직 처리되지 않은(outstanding) 패킷들에 대한 추적 상태(tracking status)를 포함할 수 있고 - 이하에 추가로 상세하게 설명될 - 타겟 시스템으로의 네트워크를 가로지르는 경로 설정 및 해지(take down)를 포함할 수 있다.

전송 컨텍스트 (624)는 메모리 (628)에 저장된 목적지-관련 정보, 예컨대 현재 어드레스 핸들과 관련된 네트워크 어드레스 맵 객체 (656)를 또한 추적할 수 있다. 네트워크 어드레스 맵 객체 (656)는 메시지 (660)를 위한 패킷들을 생성하기 위한 정보를 제공할 수 있다. 예를 들어, 네트워크 어드레스 맵 객체 (656)는 목적지 어드레스를 포함할 수 있다 (예를 들어, 타겟 시스템의 IP 어드레스 또는 Mac 어드레스, 또는 타겟 애플리케이션의 어드레스). 대안적으로 또는 추가적으로, 네트워크 어드레스 맵 객체 (656)는 타겟 시스템에 도달하기 위해 패킷에 대하여 필요한 어드레스지정(addressing) 및/또는 라우팅 정보를 포함하는 미리-생성된 헤더를 포함할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (620)는 메모리를 가지지 않을 수 있거나 또는 데이터 예컨대, 목적지-관련 정보를 저장하기 위해 호스트 디바이스 (602)상에 메모리를 사용할 수 있다. 이들 구현예들에서, 전송 컨텍스트 (624)가 네트워크 어드레스 맵 객체 (656)를 룩 업할 때, 호스트 디바이스(602) 메모리로부터 네트워크 어드레스 맵 객체 (656)를 판독하기 위해 호스트 디바이스 (602)에 요청을 둘 수 있다.

메모리에 저장된 목적지-관련 정보(656), 예컨대 네트워크 어드레스 맵 객체, (656)를 이용하여, 네트워크 어댑터 디바이스는 메시지 (660)의 전부 또는 일부를 함유하는 하나 이상의 패킷들 (662)을 생성할 수 있다. 네트워크 어드레스 맵 객체 (656)가 미리-생성된 패킷 헤더를 제공하는 구현예들에서, 패킷들 (662)은 미리-생성된 패킷 헤더를 페이로드(payload)에 덧붙임(prepend)함으로써 생성될 수 있고, 여기서 페이로드는 메시지의 (660) 데이터를 포함한다. 하나 이상의 패킷들 (662)이 생성되면, 네트워크 어댑터 (620)는 그런 다음 네트워크 (630)를 통하여 패킷 또는 패킷들을 송신할 수 있다.

일부 경우들에서, 타겟 애플리케이션은 메시지 (660)에 응답할 것이 예상된다. 예를 들어, 메시지 (660)가 타겟 애플리케이션이 갖는 일부 정보를 요청하는 판독 트랜잭션일 때, 타겟 애플리케이션은 판독 데이터로 응답할 것이 예상될 수 있다. 다른 예로서, 메시지 (660)는 하나 이상의 동작들을 실행시키고, 해당 동작들의 결과를 리턴하기 위한 타겟 애플리케이션에 대한 명령일 수 있다.

도 6b는 도 6a에 따라 송신된 메시지 (660)에 대한 답으로 발송된 응답 (664)의 수신의 예를 예시한다. 도 6b에서, 응답 (664)은 패킷의 형태로 네트워크 어댑터 디바이스 (620)에 의해 네트워크(630)를 통하여 수신될 수 있다. 네트워크 어댑터 디바이스 (620)는 호스트 디바이스 (602)상에서 실행하는 유저 애플리케이션들에 의해 송신된 메시지들에 대한 응답으로 발송된 많은 응답들을 수신할 수 있다. 네트워크 어댑터 디바이스 (620) 및/또는 호스트 디바이스 (602)는 따라서 어떤 유저 애플리케이션이 주어진 응답 (664)을 수신하여야 하는지를 식별할 수 있다. 패킷 헤더는 응답 (664)의 소스를 식별하는 정보 (예를 들어, 원격 서버 및/또는 원격 애플리케이션의 어드레스) 및 응답에 대한 목적지 (예를 들어, 로컬 서버 및/또는 유저 애플리케이션 (604))를 포함할 수 있다. 패킷 페이로드는 응답 (664) 데이터를 포함할 수 있다.

응답 (664)은 응답 (664)을 발송한 시스템을 위해 구성될 수 있는 전송 컨텍스트 (624)에 의해 수신될 수 있다. 전송 컨텍스트 (624)를 이용하여, 네트워크 어댑터 디바이스는 네트워크(630)를 통하여 수신된 패킷으로부터 응답의 (664) 데이터를 언팩(unpack)할 수 있다. 일부 경우들에서, 네트워크 어댑터 디바이스 (620)는 네트워크(630)를 통하여 수신된 다수의 응답 패킷들로부터 응답 메시지를 어셈블할 수 있다. 네트워크 어댑터 디바이스 (620)는 응답 (664)으로부터, 소스 어드레스, 즉, 응답 (664)을 발송한 시스템 및/또는 프로세스의 어드레스를 또한 추출할 수 있다. 이 예에서, 소스 어드레스는 도 6a에서 메시지 (660)를 송신하기 위해 사용된 목적지 어드레스와 동일한다. 일부 구현예들에서, 응답 (664)은 응답의 소스를 식별하는 일부 다른 정보 및/또는 응답 (664)이 대응하는 메시지 (660)를 포함할 수 있다.

도 6b로 돌아가서, 네트워크 어댑터 디바이스 (620)는 메모리 (628)에서, 발신자 어드레스에 대응하는 네트워크 어드레스 맵 객체 (656) 위치를 찾기 위해 소스 어드레스 (또는 응답 (664)을 식별하는 다른 정보)를 사용할 수 있다. 네트워크 어드레스 맵 객체 (656)는 메시지 (660)를 발송하기 위해 사용된 어드레스 핸들을 제공할 수 있다. 이 어드레스 핸들은 메시지 (660)를 발송한 유저 애플리케이션 (604)을 식별할 수 있다. 어드레스 핸들은 응답 (664)과 함께 호스트 디바이스에 제공될 수 있고, 호스트 디바이스 (602)는 (예를 들어, 드라이버 프로그램을 이용하여) 응답 메시지 (666)를 유저 애플리케이션 (604)에 보낼 수 있다. 대안적으로, 일부 구현예들에서, 응답 메시지 (666)는 어드레스 핸들보다는 네트워크로부터 응답(664)과 함께 착신된 소스 어드레스를 갖는 호스트 디바이스 (602)에 제공될 수 있다. 호스트 디바이스는 그런 다음 응답 메시지 (666)를 유저 애플리케이션 (604)에 보내기 위해 소스 어드레스를 대신 사용할 수 있다.

유저 애플리케이션 (604)은 어디서 응답 메시지 (666)가 오는지, 및/또는 응답 메시지 (666)가 어느 메시지에 응답하는지를 결정하기 위해 어드레스 핸들(address handle)을 사용할 수 있다. 앞에서 언급한 바와 같이, 어드레스 핸들은 원래 메시지 (660)가 송신된 때 어드레스 핸들과 동일할 수 있고, 이 경우에 유저 애플리케이션 (604)은 응답 메시지 (666)가 어느 메시지 대한 것 인지를 결정하기 위해 간단한 룩 업 메커니즘들을 사용할 수 있다. 일부 경우들에서, 유저 애플리케이션 (604)은 응답 메시지, (666)에 반응할 수 있는데, 예컨대 예를 들어 메시지 (660)의 전부 또는 일부를 재송신할 수 있고, 또는 목적지와 새로운 통신을 개시할 수 있다.

상기에서 언급한 바와 같이, 일부 구현예들에서, 유저 애플리케이션 (604)은 어드레스 핸들 외에 어드레스 정보를 이용하여 메시지들을 송신할 수 있다. 이들 구현예들에서, 유저 애플리케이션 (604)은 도면들 6a-6b에 예시된 프로세스 (600)에 유사한 프로세스를 사용할 수 있다. 예를 들어, 도 6a에서, 유저 애플리케이션 (604)은 네트워크상에 상이한 시스템상에서 운용하는 다른 애플리케이션으로 발송하기 위한 메시지를 가질 수 있다. 이 예에서, 유저 애플리케이션 (604)은 목적지 애플리케이션에 대한 어드레스 핸들을 가지지 않지만, 그러나 어드레스 핸들을 획득하기 위해 사용할 목적지 정보를 가질 수 있다. 예를 들어, 유저 애플리케이션 (604)는 (예를 들어) IP 어드레스 및/또는 Mac 어드레스의 형태로 목적지 시스템에 대한 네트워크 어드레스를 가질 수 있다. 다른 예로서, 유저 애플리케이션은 플로우 식별자(flow identifier)를 가질 수 있다. 플로우는 시스템과 다른 것 상에서 이동하는 전형적으로 서로에 관련된 패킷들의 스트림(stream)을 설명한다. 플로우 식별자는 동일한 플로우에 속하는 패킷들을 식별할 수 있다. 플로우 식별자는 패킷들의 헤더에 포함될 수 있는 값의 형태를 취할 수 있다. 대안적으로 또는 추가적으로, 플로우는 네트워크 어드레스들, 예컨대 소스 시스템의 어드레스, 목적지 시스템의 어드레스, 패킷들이 발송된 소스 시스템에서의 포트, 및/또는 패킷들이 수신된 목적지 시스템에서의 포트에 의해 식별될 수 있다. 일부 경우들에서, 플로우 식별자는 입력들로서 소스 및 목적지 및/또는 포트들을 사용하는 수학 연산의 결과이다.

유저 애플리케이션 (604)은 따라서 메시지 (660)를 발송하기 위해 목적지 정보를 사용할 수 있다. 유저 애플리케이션 (604)은 목적지 정보를 가지고, 네트워크 어댑터 디바이스 (620)로 메시지 (660)를 발송할 수 있다. 네트워크 어댑터 디바이스 (620)는 적절한 전송 컨텍스트 (624)를 결정하기 위해 목적지 정보를 사용할 수 있다. 예를 들어, 네트워크 어댑터 디바이스 (620)는 네트워크 어드레스 또는 플로우 식별자를 이용하여 전송 컨텍스트 (624)를 룩 업 하도록 구성될 수 있다. 일단 네트워크 어댑터 디바이스 (620)가 전송 컨텍스트 (624)를 결정한 후에, 네트워크 어댑터 디바이스 (620)는 전송 컨텍스트 (624)를 이용하여, 패킷들을 생성하고 패킷들을 네트워크 (630)로 송신할 수 있다.

도면들 5a-5b 및 6a-6b에 예시된 바와 같이 무접속 메시지 전송 프로세스들 (500,600)을 사용하도록 구성된 컴퓨트 클러스터들은 네트워크 어드레스들을 더 효율적으로 관리할 수 있고, 더 낮은 메모리 수요들을 가질 수 있고, 더 확장가능할 수 있다.

무접속 메시지 전송으로 제공된 어드레스 핸들들은 호스트 디바이스내 어드레스 관리를 단순화할 수 있다. 무접속 메시지 전송 방법들을 사용하지 않는 구현예들에서, 어드레스 관리의 더 많은 부담(burden)은 호스트 디바이스상에서 실행하는 소프트웨어상에 배치될 수 있다. 예를 들어, 소스 및 목적지 정보의 추적을 요하는 패킷 헤더들을 생성하기 위해 유저 애플리케이션 또는 드라이버 프로그램이 요구될 수 있다. 다른 예로서, 응답이 수신된 때, 드라이버 프로그램 또는 유저 애플리케이션은 응답에 대한 소스 및 목적지를 식별하기 위해 전체 패킷 헤더를 판독하는 것이 요구될 수 있다. 그에 반해서, 무접속 메시지 전송 방법들을 사용하는 구현예들에서, 일단 목적지 어드레스가 등록된 후에, 유저 애플리케이션들 및 드라이버 프로그램들은 단지 목적지를 나타내는 어드레스 핸들 사용이 요구된다. 더욱이, 응답이 호스트 디바이스 (602)에 의해 수신된 때, 그것은 그것의 어드레스 핸들에 의해 빠르게 식별될 수 있다.

어드레스 핸들들은 또한 하나의 시스템상에서 실행하는 많은 프로세스들이 상이한 시스템상에서 실행하는 많은 프로세스들과 통신할 때 요구되는 메모리의 양을 줄일 수 있다. 유저 애플리케이션이 통신하려고 하는 각각의 목적지에 대하여, 유저 애플리케이션은 별개의 어드레스 핸들을 획득하고 유지할 수 있다. 각각의 목적지에 대하여, 그러나, 목적지와 통신할 수 있는 모든 유저 애플리케이션들에 대하여 단지 하나의 네트워크 어드레스 맵 객체가 생성되고 저장될 필요가 있다. 네트워크 어댑터에서 메모리 사용량이 따라서 최소화될 수 있다. 드라이버 프로그램에 대한 메모리 요구들이 또한 최소화될 수 있는데, 왜냐하면 드라이버 프로그램은 일부 구현예들에서, 어드레스 핸들들을 획득하기 위해 호스트 디바이스상에서 실행하는 모든 프로세스들에 의해 사용될 수 있는 어드레스 맵을 유지할 수 있기 때문이다. 추가적으로, 일단 목적지 어드레스가 드라이버 프로그램에 등록된 후에, 동일한 목적지와 통신하기 위해 다른 유저 애플리케이션들에 어드레스 핸들들을 제공하는 것이 네트워크 어댑터 디바이스와 통신할 필요 없이 빠르게 이루어질 수 있다.

무접속 메시지 전송(connectionless message transfer)은 컴퓨팅 클러스터에 더 큰 확장성을 또한 제공할 수 있다. 상기에서 언급한 바와 같이, 연결된 전송 서비스 유형들로 일어날 수 있는 문제들 중 하나는 네트워크에 걸쳐 통신을 시도하는 프로세스들의 수가 증가할수록, 연결들의 수도 증가한다는 것이다. 그에 반해서, 무접속 메시지 전송 방법들을 사용하는 구현예들에서, 유저 애플리케이션들은 연결들을 수립할 필요가 없고, 대신 어드레스 핸들들을 획득한다. 네트워크 어댑터 디바이스가 다른 시스템들과 연결들을 수립하지 않지만, 대부분의 경우들에서 단지 하나의 연결이 네트워크상의 임의의 두개의 시스템들간에 수립된다. 하나의 시스템으로부터의 모든 트래픽은 그런 다음 다른 시스템에 도달하기 위해 단일 연결을 사용할 수 있다. 따라서, 연결들의 수는 프로세스들의 수가 증가할수록 증가하지 않을 것이고, 단지 클러스터에 추가되는 더 많은 노드들의 결과로서 증가한다.

II. 신뢰할 수 있는 순서가 바뀐 패킷 전달 (RELIABLE OUT-OF-ORDER PACKET DELIVERY)

상기에서 논의된 바와 같이, “무접속(connectionless)” 메시지 전송은 완화된 신뢰할 수 있는 데이터그램 전송 서비스에 의해 가능하게 될 수 있다. 이 섹션은 어떻게 메시지들이 어드레스 지정될 수 있는지, 어떻게 네트워크와 통신이 관리되는지, 및 신뢰할 수 있는 전달을 제공하기 위한 메커니즘들을 포함하여 완화된 신뢰할 수 있는 데이터그램 전송을 이용하여 더 상세하게 메시지 전송의 관리를 논의한다. 또한 어떻게 그리고 왜 패킷들이 순서가 바뀌어 도달할 수 있는지에 대한 논의가 제공된다.

도면들 7a-7b는 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 포함하는 시스템들에 대해 구현될 수 있는 통신 스택(700)의 예를 예시한다. 도 7a는 통신 스택의 송신 측의 예를 예시하고, 도 7b는 통신 스택의 수신 측의 예를 예시한다. 이들 예들에서, 연결들은 예를 들어, 도면들 5a-5b에 대하여 설명된 프로세스 (500)를 이용하여 미리 수립될 수 있다. 예를 들어, 도면들 7a-7b에서 하나 이상의 송신-측 전송 컨텍스트들 (716a-b) 및 수신된-측 전송 컨텍스트들 (768a-b)은 (이 예에 따라) 각각의 송신-측 전송 컨텍스트 (716a-b)가 대응하는 수신-측 전송 컨텍스트 (768a-b)와의 연결을 관리하도록 구성될 수 있다. 도면들 7a-7b의 예제는 송신 시스템으로서 하나의 시스템 및 수신 시스템으로서 다른 시스템을 예시하지만, 라벨들 “송신(transmit)” 및 “수신(receive)”은 편의 목적을 위해서만 할당된다. 여기에서 수신-측 시스템으로 불리우는 시스템은 또한 송신 시스템으로 기능을 할 수 있고, 여기에서 송신 시스템으로 불리우는 시스템은 수신 시스템으로 동작할 수 있다는 것이 추가로 이해된다.

도 7a의 예제에서, 예제 통신 스택 (700)의 송신 측이 예시된다. 이 예에서, 통신 스택의 송신 측은 하나 이상의 목적지 시스템들 (718a-b)과 네트워크(730)를 통하여 통신하는 두개의 유저 애플리케이션들 (704a-b), 많은 큐 쌍들 (710a-d), 및 하나 이상의 송신-측 전송 컨텍스트들 (716a-b)을 포함한다. 도 7a에 예시된 예제는 단순화를 위하여 두개의 유저 애플리케이션들 (704a-b)을 설명하고, 예시된 가상 기계 (702) 및/또는 가상 기계 (702)를 호스트하는 시스템은 유저 애플리케이션들보다 더 많거나 또는 더 적을 수 있고, 각각이 유사한 통신 스택을 사용하도록 구성된다는 깃이 이해된다.

이 예에서, 유저 애플리케이션들 (704a-b)은 호스트 디바이스를 위해 구성된 가상 기계 (702)내에서 실행될 수 있다. 각각의 유저 애플리케이션 (704a-b)은 네트워크 (730)와 통신하기 위해 표준 라이브러리 (706a-b), 예컨대 OFED-유형 버브 라이브러리를 사용할 수 있다. 일부 구현예들에서, 각각의 유저 애플리케이션 (704a-b)은 상이한 표준 라이브러리 (706a-b)를 이용할 수 있다. 표준 라이브러리들 (706a-b)은 공통 셋의 네트워크 명령들, 예컨대 메시지들을 발송하기 위해 "포스트 발송(post send)", 메시지들을 수신하기 위해 "포스트 수신(post receive)", 및 완료(completion) 큐의 컨텐츠들을 체크하기 위해 "폴(poll)"을 제공할 수 있다. 표준 라이브러리들 (706a-b)은 드라이버 프로그램 (708a-b)에 인터페이스를 또한 제공할 수 있다. 드라이버 프로그램 (708a-b)은 네트워크 어댑터 디바이스를 포함하여 가상 기계 (702) 운영 체제 커널 및/또는 시스템의 하드웨어와 상호 작용하기 위한 명령들을 제공할 수 있다. 드라이버 프로그램 (708a-b)은 커널 드라이버일 수 있고, 이 경우에 드라이버 프로그램 (708a-b)은 더 높은 액세스 권한들을 가질 수 있다. 대안적으로, 드라이버 프로그램 (708a)은 유저 스페이스 드라이버일 수 있고, 더 낮은 액세스 권한들을 가진다. 일부 구현예들에서, 각각의 유저 애플리케이션 (704a-b)은 상이한 드라이버 프로그램 (708a-b)을 이용할 수 있다. 다른 구현예들에서, 양쪽 유저 애플리케이션 (704a-b)은 동일한 드라이버 프로그램 (708a-b)을 이용할 수 있다. 일부 구현예들에서, 유저 애플리케이션 (704a-b)은 표준 라이브러리 (706a-b)를 통하여 라기보다는 드라이버 프로그램 (708a-b)와 직접 통신할 수 있다.

네트워크 (730)와 통신하기 위해서, 각각의 유저 애플리케이션 (704a-b)은 하나 이상의 “통신 엔드 포인트들(communication endpoints)”에 할당될 수 있다. 통신 엔드 포인트는 유저 애플리케이션들 (704a-b)와 로직상의 연관을 설명하고, 유저 애플리케이션들 (704a-b)에 의해 발송된 메시지들에서 유저 애플리케이션들 (704a-b)을 식별하기 위해 사용될 수 있다. 즉, 통신 엔드 포인트의 식별자는 적어도 부분적으로, 메시지에 대한 발신자 어드레스로서 사용될 수 있다. 통신 엔드 포인트들은 상이한 방식들로 구현될 수 있다. 예를 들어, 일부 구현예들에서, 예제 통신 스택 (700)에서, 통신 엔드 포인트들은 큐 쌍 (710a-d)에 각각 매핑된다. 이들 구현예들에서, 통신 엔드 포인트는 전형적으로 숫자인 큐 쌍 식별자에 의해 식별될 수 있다. 더욱이, 이들 구현예들에서, 큐 쌍 식별자는 적어도 부분적으로, 유저 애플리케이션들 (704a-b)에 의해 발송된 메시지들에 대한 발신자 어드레스로서 사용될 수 있다. 유저 애플리케이션 (704a-b)에 할당된 통신 엔드 포인트들은 드라이버 프로그램 (708a-b)에 의해 유지될 수 있다. 통신 엔드 포인트들은 대부분의 경우들에서, 유저 애플리케이션들간에 공유되지 않는다.

가상 기계 (702)는 그 자체가 네트워크 (730)와 통신하기 위해 하나 이상의 가상 인터페이스들 (709a-b)을 할당받을 수 있다. 이들 가상 인터페이스들 (709a-b)은 예를 들어, 가상 기계의 (702) 운영 체제에 의해 또는 호스트 디바이스의 운영 체제에 의해 가상 기계 (702)에 할당될 수 있다. 각각의 가상 인터페이스 (709a-b)는 IP 어드레스를 할당받을 수 있다. 네트워크 (730)와 통신하기 위해서, 유저 애플리케이션 (704a-b)은 하나 이상의 가상 인터페이스들 (709a-b)을 사용할 수 있다. 따라서, 예를 들어, 두개의 이용 가능한 가상 인터페이스들 (709a) 중 하나를 이용하여, 유저 애플리케이션들 (704a-b)에 의해 발송된 메시지는 메시지에 대한 발신자 어드레스로서 해당 가상 인터페이스의 IP 어드레스를 가질 수 있다. 일부 구현예들에서, 유저 애플리케이션 (704a-b)은 따라서 이 가상 인터페이스 (709a)의 IP 어드레스에 의해 식별될 수 있다.

유저 애플리케이션들 (704a-b)이 그 자신들을 가상 기계 (702) 운영 체제 커널에 등록하였을 때, 및/또는 유저 애플리케이션들 (704a-b)이 큐 쌍 (710a-d)에 할당을 요청하였을 때, 및/또는 유저 애플리케이션들 (704a-b)이 목적지 시스템 (718a-b)과 통신하기 위해 먼저 등록된 때 가상 인터페이스들 (709a-b)은 유저 애플리케이션들 (704a-b)에 할당될 수 있다. 일부 구현예들에서, 하나 초과의 유저 애플리케이션 (704a-b)은 주어진 가상 인터페스들 (709a-b)을 사용할 수 있다. 예를 들어, 도 7a의 예제에서, 제1 유저 애플리케이션 (704a) 및 제2 유저 애플리케이션 (704b)은 제 2 가상 인터페이스 (709b)에 둘 모두 할당되었다.

이들 및 다른 구현예들에서, 유저 애플리케이션들 (704a-b)은 네트워크 (730)와 통신학 위해 통신 엔드 포인트 및 하나 이상의 가상 인터페이스들 (709a-b)을 이용할 수 있다. 이들 구현예들에서, 유저 애플리케이션들 (704a-b)은 통신 엔드 포인트의 식별자 (예를 들어, 큐 쌍 번호) 및 가상 인터페이스의 (709a-b) IP 어드레스의 조합에 의해 식별될 수 있다. 더욱이, 가상 인터페이스들의 (709a-b) IP 어드레스 및 통신 엔드 포인트 식별자의 조합은 유저 애플리케이션들 (704a-b)에 의해 발송된 메시지들에 대한 발신자 어드레스로서 사용될 수 있다.

상기에서 언급한 바와 같이, 일부 구현예들에서 (완화된 신뢰할 수 있는 데이터그램 전송을 이용하는 것들을 포함), 각각의 통신 엔드 포인트는 개별 큐 쌍 (710a-d)에 매핑될 수 있다. 큐 쌍들은 일반적으로 네트워크로 송신되는 메시지들을 위한 발송 큐 (712) 및 네트워크 (730)로부터 들어오는 메시지들을 수신하기 위한 수신 큐(714)를 포함한다. 일부 구현예들에서, 유저 애플리케이션 (704a-b)에 할당된 각각의 통신 엔드 포인트는 상이한 큐 쌍 (710a-d)에 할당될 수 있다. 다른 구현예들에서, 큐 쌍들은 통신 엔드 포인트들간에 공유될 수 있지만, 그러나 이들 구현예들에서 각각의 통신 엔드 포인트가 고유하게 어드레스 지정되고 식별되는 것을 보장하기 위해 제한들 및/또는 추가의 파라미터들이 구성에 추가되는 것을 필요로 할 수 있다.

많은 경우들에서, 큐 쌍들 (710a-d)은 네트워크 어댑터 디바이스상에 하드웨어로 구현될 수 있지만, 그러나 일부 경우들에서 큐 쌍들 (710a-d)은 네트워크 어댑터 디바이스상에 소프트웨어로 구현될 수 있고, 및/또는 호스트 디바이스상의 소프트웨어로 구현될 수 있고, 및/또는 호스트 디바이스의 운영 체제에 및/또는 하이퍼바이저에, 가상 기계들을 생성하고 관리하는 하드웨어 및/또는 소프트웨어 계층에 존재할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (또는 운영 체제 또는 하이퍼바이저)는 큐 쌍 (710a-d)이 유저 애플리케이션 (704a-b), 드라이버 프로그램 (708a-b)에 의해 요청된 때, 또는 유저 애플리케이션 (704a-b)이 드라이버 프로그램 (708a-b)를 통하여 요청을 만든 때 큐 쌍 (710a-d)을 할당할 수 있다. 일부 구현예들에서, 하나의 큐 쌍 (예를 들어, 큐 쌍 번호 제로 또는 일)이 관리 메시지들, 예컨대 연결들을 설정하거나 해지하기 위한 메시지들 및 그것들의 개별 어드레스들을 교환하기 위해 유저 애플리케이션들간에 전달된 메시지들을 전달하기 위해 리저브(reserve)될 수 있다.

상기에서 언급한 바와 같이, 일부 구현예들에서, 큐 쌍 (710a-d) (예를 들어, 제1 큐 쌍 (710a))은 특정 유저 애플리케이션 (704a-b) (예를 들어, 제1 유저 애플리케이션 (704a))과 관련된 통신 엔드 포인트에 할당될 수 있다. 큐 쌍 (710a)은, 그러나, 특정 목적지와 연관될 필요가 없어서 네트워크상에 상이한 목적지들로 타겟된 유저 애플리케이션 (704a)로부터 메시지들을 수신할 수 있다.

일부 구현예들에서, 큐 쌍 (710a-d) 할당은 각각의 가상 인터페이스 (709a-b)에 대하여 추적될 수 있다. 일부를 수행하는 것은 예를 들어, 가상 기계 (702)의 마이그레이션(migration)을 가능하게 할 수 있다. 마이그레이션은 가상 기계 (702)를 먼저 셧 다운하거나 또는 셧 다운하지 않고 가상 기계 (702)를 상이한 물리적 시스템으로 이동시키는 프로세스이다. 가상 기계 (702)의 마이그레이션 후에, 통신 엔드 포인트들이 새로운 큐 쌍들에 할당될 수 있지만, 그러나 구(old) 큐 쌍 식별자들이 유지되기 때문에 계속 전송중인(in flight) 패킷들은 이들 통신 엔드 포인트들에 또한 도달할 수 있다.

상기에서 논의된 바와 같이, 유저 애플리케이션들 (704a-b)은 유저 애플리케이션들 (704a-b)에 할당된 통신 엔드 포인트의 아이덴티티(identity)에 의해, 유저 애플리케이션들 (704a-b)에 의해 사용되는 가상 인터페이스 (709a-b)의 IP에 의해, 또는 가상 인터페이스 (709a-b)의 통신 엔드 포인트 및 IP 어드레스의 양쪽 아이덴티티에 의해 식별될 수 있다. 타겟 유저 애플리케이션 (예를 들어, 도 7b에 예시된 유저 애플리케이션 (754))이 유사한 방식으로 식별될 수 있다.

이제 도 7a에 예시된 특정 예제로 가서, 이 예에서, 제1 유저 애플리케이션 (704a)은 세 개의 예시된 큐 쌍들 (710a-c)에 의해 표시된 적어도 세 개의 통신 엔드 포인트들로 구성되었다. 더욱이, 제 1 유저 애플리케이션 (704a)은 하나의 이용 가능한 가상 인터페이스 (709a) (제 1 큐 쌍 (710a)과 통신을 나타내는 실선 화살표 (720a)로 표시된)를 갖는 하나의 통신 엔드 포인트와 연관되고 제 2 이용 가능한 가상 인터페이스 (709b) (제 2 (710b) 및 제 3 (710c) 큐 쌍과 통신을 나타내는 파선 화살표 (720b)로 표시된)를 갖는 두개의 통신 엔드 포인트들과 추가로 연관된다. 추가로 예제로서, 제 2 유저 애플리케이션 (704b)은 제 4 큐 쌍 (710d)로 점선(dotted) 화살표 (726)에 의해 표시된 하나의 통신 엔드 포인트로 구성되었다. 더욱이, 제 2 유저 애플리케이션 (704b)은 제 2 가상 인터페이스 (709b)를 갖는 이 통신 엔드 포인트와 관련된다.

이 예에서, 제 1 유저 애플리케이션 (704a)은 네트워크 (730)상에 목적지 시스템 (718a)으로 송신하기 위한 메시지를 가질 수 있다. 그것의 제 1 통신 엔드 포인트를 이용하여, 제 1 유저 애플리케이션 (704a)은 통신 엔드 포인트와 관련된 제 1 큐 쌍 (710a)의 발송 큐 (712)에 메시지에 대한 목적지 시스템 (718a)을 식별하는 정보 (예를 들어, 어드레스 핸들)와 함께 메시지를 둘 수 있다. 메시지를 발송 큐 (712)에 두는 것은 전형적으로 호스트 디바이스 프로세서의 보조를 필요로 하지 않는다. 추가적으로, 발송 큐 (712)에 메시지를 두는 것은 전형적으로 또한 큐 쌍 (710a)에 액세스를 위해 유저 애플리케이션 (704a)에 의한 중재(arbitration)을 필요로 하지 않는데, 이는 대부분의 경우들에서, 유저 애플리케이션 (704a)이 큐 쌍 (710a)의 독점 사용을 갖기 때문이다.

일부 구현예들에서, 네트워크 어댑터 디바이스가 큐 쌍들 (710a-d)을 관리한다. 네트워크 어댑터 디바이스는 큐 쌍들 (710a-d)이 시기 적절한(timely) 방식으로 서비스되는 것을 보장할 수 있다. 대안적으로 또는 추가적으로, 네트워크 어댑터 디바이스는 각각의 큐 쌍 (710a-d)에 할당된 우선권(priority), 트래픽 유형, 및/또는 서비스 레벨 계약(agreement)에 따라 큐 쌍들 (710a-d)을 서비스할 수 있다.

계속해서 도 7a의 예제에서, 제 1 발송 큐 (712)가 서비스될 때, 네트워크 어댑터 디바이스는 유저 애플리케이션 (704a)에 의해 발송 큐 (712)에 둔 메시지를 제거 및 프로세스 (예를 들어, 펌웨어 또는 집적 회로를 이용하여) 할 수 있다. 네트워크 어댑터는 메시지와 함께 발송 큐 (712)로 푸시(push)된 목적지 정보를 조사할 수 있고, 적절한 전송 컨텍스트 (716a-b)를 식별할 수 있다. 앞에서 논의한 바와 같이, 전송 컨텍스트들 (716a-b) 각각은 네트워크상에서 목적지 시스템 (718a-b)과 연결을 관리한다. 대부분의 구현예들에서, 전송 컨텍스트 (716a)는 하나의 소스 시스템과 하나의 목적지 시스템 사이의 연결을 설명하고, 특정 유저 애플리케이션 또는 큐 쌍과 관련되지 않는다. 따라서, 상이한 유저 애플리케이션들로부터, 및/또는 상이한 통신 엔드 포인트들을 통하여 발송된 메시지들이, 동일한 전송 컨텍스트 (716a)에 매핑될 수 있다. 반대로, 하나의 유저 애플리케이션 (704a)로부터의 메시지들이 상이한 전송 컨텍스트들 (716a-b)로 보내질 수 있다. 예를 들어, 예시된 예제에서, 제 1 유저 애플리케이션 (740a)에 매핑된 제 1 큐 쌍 (710a)로부터의 메시지들은, 제 1 전송 컨텍스트 (716a) (실선 화살표 (722a)에 의해 표시된) 및 제 2 전송 컨텍스트 (716b) (파선 화살표 (722b)에 의해 표시된)로 보내질 수 있다. 유사하게, 제 2 유저 애플리케이션 (704b)에 매핑된 제 4 큐 쌍 (710d)으로부터 메시지들은, 양쪽 전송 컨텍스트들 (716a-b) (점선 화살표 (728)에 의해 표시된)에 또한 보내질 수 있다. 각각의 큐 쌍들 (710a-d)은 여기에 예시되지 않은 추가의 전송 컨텍스트들에 메시지들을 추가로 보낼 수 있다. 특정 메시지에 대한 전송 컨텍스트 (716a-b)는 메시지와 함께 제공된 목적지 정보에 의해 식별될 수 있다.

일부 구현예들에서, 전송 컨텍스트들 (716a-b) (예를 들어, 제 2 전송 컨텍스트 (716b))은 신뢰할 수 있는 연결 전송에 유사한 전송 서비스를 제공하도록 구성될 수 있다. 이들 구현예들에서, 전송 컨텍스트 (716b)는 단일 큐 쌍 (예를 들어, 제 2 큐 쌍 (710b))에 할당될 수 있다. 수신 측에서, 대응하는 수신-측 전송 컨텍스트 (768b)가 단일 큐 쌍 (예를 들어, 제 2 큐 쌍 (760b))에 또한 할당될 것이다. 전송 컨텍스트들 (716b), (768b)를 각각의 단일 큐 쌍에 할당하는 것은 전송 컨텍스트들 (716b), (768b)이 신뢰할 수 있는 연결 전송을 제공하는 경우인 것처럼 발송 유저 애플리케이션 (704a) 및 수신 유저 애플리케이션 (754)이 서로에 독점 통신 채널을 갖는 것으로 귀결될 수 있다. 전송 컨텍스트들 (716b), (768b)은 사실은, 완화된 신뢰할 수 있는 데이터그램 전송을 제공하는 것 일 수 있고, 이는 신뢰할 수 있는 연결인 것 처럼 패킷 전달을 보장할 수 있다.

계속해서 도 7a의 예제로, 이 예에서, 제 1 전송 컨텍스트 (716a)는 제 1 발송 큐 (712)로부터 팝핑된(popped) 메시지에 대한 전송 컨텍스트로서 식별된다. 일부 구현예들에서, 전송 컨텍스트 (716a)는 미리-생성된 패킷 헤더를 제공할 수 있다. 미리-생성된 패킷 헤더는 미리 결정된 소스 및 목적지 어드레스들, 및/또는 송신 측으로부터 수신 측으로 패킷을 라우팅하는데 필요한 다른 정보를 포함할 수 있다. 일부 구현예들에서, 전송 컨텍스트 (716a)는 패킷들이 터널링 될 상황들을 위하여 미리-생성된 내부 및 외부 헤더들을 제공할 수 있다.

앞에서 언급된 바와 같이, 전송 컨텍스트들 (716a-b)은 네트워크 (730)상에 대응하는 목적지 시스템 (718a-b)과 연결을 관리할 수 있다. 전형적으로, 예컨대 컴퓨팅 클러스터에는, 송신 측 시스템으로부터 수신 측 시스템까지 이용 가능한 다수의 경로들 (724a-b)이 있을 수 있다. 이런 상황들에서, 전송 컨텍스트들 (716a-b)은 네트워크 (730)에 걸친 다수의 이용 가능한 경로들 (724a-b)을 관리할 수 있다. 경로들 (724a-b)의 관리는 경로들 (724a-b) 설정 및 해지를 포함할 수 있고, 여기서 경로들 (724a-b)은 그것들이 너무 혼잡되거나 또는 해당 경로를 따라서 링크 고장이 있다면 중지될 수 있다. 추가적으로, 전송 컨텍스트들 (716a-b)은 모든 이용 가능한 경로들 (724a-b)를 걸쳐 패킷들을 송신하려고 또한 시도할 것이다. 그렇게 하는 것은 네트워크에 걸쳐 부하 분산을 개선시킬 수 있고 및/또는 최신의 혼잡되거나 또는 고장 경로들에 대한 정보를 유지하는 것을 돕는다. 예를 들어, 패킷들이 목적지 시스템 (718a)에 도달되지 않거나, 또는 목적지 시스템 (718a)에 도달하는데 오래 걸리는 때 혼잡되고 고장난 경로들이 검출될 수 있다. 네트워크에 걸친 다수의 경로들 (724a-b)의 관리가 도 8에 대하여 추가로 상세하게 설명된다.

계속해서 도 7a에 예시된 예제, 이 예에서, 제 1 전송 컨텍스트 (716a)는 메시지를 제 1 유저 애플리케이션 (704a)로부터 다수의 경로들 (724a)를 이용하여 네트워크(730)를 통하여 목적지 시스템 (718a)로 송신할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 메시지를 포함하는 하나의 패킷을 생성하고 발송하기 위해 전송 컨텍스트 (716a)를 사용할 수 있다. 일부 구현 예들에서, 네트워크 어댑터 디바이스는 다수의 패킷들을 생성할 수 있고, 각각은 메시지의 일부를 함유한다. 이들 다수의 패킷들은 목적지 시스템 (718a)에 도달하기 위해 동일한 경로 또는 상이한 경로들을 각각 취할 수 있다. 일부 구현예들에서, 이하에서 더 상세하게 설명되는 것처럼, 전송 컨텍스트 (716a) 은 각각의 패킷이 목적지 시스템 (718a)에 전달되는 것을 보장하기 위해 각각의 패킷에 대한 상태를 모니터링할 수 있다.

도 7b는 통신 스택 (700)의 수신 측을 예시한다. 송신 측에서처럼, 수신 측은 유저 애플리케이션 (754), 하나 이상의 큐 쌍들 (760a-b), 및 네트워크 (730)상에 대응하는 소스 시스템들 (766a-b)과 통신하는 하나 이상의 수신-측 전송 컨텍스트들 (772a-b)을 포함한다. 도 7b에 의해 예시된 예제에서, 예시된 유저 애플리케이션 (754)이 도 7a의 예시 송신 측에 예에 예시된 적어도 (반드시 배타적이 아니더라도) 제 1 유저 애플리케이션 (704a)와 통신하도록 구성되었다. 따라서, 도 7b에 예시된 예제에서, 제 1 소스 시스템 (766a)은 도 7a에 예시된 송신-측 시스템에 해당한다. 더욱이, 도 7b에서, 전송 컨텍스트 (766a)는 소스 시스템 (766a)과 통신하도록 구성되었고, 소스 시스템 (766a)에서 전송 컨텍스트 (716a)과 연결을 관리할 수 있다. 유사하게, 제 2 소스 시스템 (766b)은 또한 도 7a에 예시된 송신-측 시스템에 대응하지만, 그러나 상이한 송신-측 전송 컨텍스트 (716b)에 연결하도록 구성된다.

도 7b는 유저 애플리케이션 (754)이 메시지들 송신 및 수신을 위해 버퍼들 (782)을 어떻게 구성할 수 있는지를 또한 예시한다. 예시되지 않았지만, 도 7a의 송신 측 유저 애플리케이션 (704a)이 그것들이 필요하다면 버퍼들을 또한 구성할 수 있다. 도 7b에서, 유저 애플리케이션 (754)은 전형적으로, 항상은 아니지만, 가상 기계 (752)내에서 실행될 수 있다. 일부 구현예들에서, 가상 기계 (752)는 가상 메모리 (780)를 제공할 수 있고, 여기서 유저 애플리케이션 (754)은 버퍼들 (782)을 위한 스페이스를 할당할 수 있다. 이들 구현예들에서, 버퍼들 (782)의 어드레스들은 가상일 수 있고, 가상 기계 (752)의 가상 어드레스 스페이스에 존재할 수 있다. 많은 경우들에서, 가상 어드레스들은 운영 체제 커널에 (가상 기계 운영 체제 또는 호스트 디바이스 운영 체제), 네트워크 (730)에 대한 액세스를 제공하는 네트워크 어댑터에 등록될 수 있다. 커널에 등록은 게스트(guest) 물리적 어드레스들에 가상 어드레스들의 매핑을 고정시킬 수 있고, 이는 버퍼들 (782)을 포함하는 가상 페이지들이 스왑핑되어, 일부 비효율을 초래 하는 것을 방지할 수 있다. 커널에 등록은 가상 기계 (752)내에서 또는 호스트 시스템 상에서 실행하는 커널 드라이버를 통하여 성취될 수 있다. 커널 드라이버는 등록 정보를 네트워크 어댑터 디바이스에 전달할 수 있고, 이는 메모리 등록 키들을 리턴할 수 있다. 메모리 등록 키들은 이어서 유저 애플리케이션에 의해 발송된 메시지들을 갖는 네트워크 어댑터 디바이스로 버퍼 (782) 어드레스들과 함께 유저 애플리케이션 (754)에 의해 전달될 수 있다. 등록 키들을 획득하는 이 프로세스는 호스트 디바이스 프로세서로부터의 보조 필요 없이 버퍼들 (782)로부터 직접 판독하고 거기에 기록하는 권한을 갖는 액세스를 네트워크 어댑터 디바이스에 제공할 수 있다.

일부 구현예들에서, 유저 애플리케이션 (754)은 가상 메모리 대신 또는 그것에 추가하여 호스트 디바이스의 물리적 메모리에 버퍼들 (782)을 할당할 수 있다. 이들 구현예들에서, 유저 애플리케이션 (754)은 특별한 신뢰된 상태를 가질 수 있는데, 이는 물리적 메모리에 대한 유저 애플리케이션 액세스를 주는 것은 유저 애플리케이션 (754)을 단지 가상 메모리에 제한하는 것보다 덜 안전하기 때문이다.

일부 구현예들에서, 유저 애플리케이션 (754)은 네트워크 (730)와 통신하기 위해 표준 라이브러리 (756), 예컨대 OFED-유형 버브 라이브러리(verbs library)를 사용할 수 있다. 표준 라이브러리들 (756)은 드라이버 프로그램 (708a)에 인터페이스를 제공할 수 있다. 드라이버 프로그램 (708a)은 네트워크 어댑터 디바이스를 포함하여 가상 기계 (752) 운영 체제 커널 및/또는 시스템의 하드웨어와 상호 작용하기 위한 명령들을 제공할 수 있다. 일부 구현예들에서, 유저 애플리케이션 (754)은 표준 라이브러리 (756)를 통하여 라기보다는 드라이버 프로그램 (758)와 직접 통신할 수 있다.

네트워크 (730)와 통신하기 위해서, 유저 애플리케이션 (754)은 이 예제에서 하나 이상의 통신 엔드 포인트들을 할당받을 수 있다. 일부 구현예들에서, 각각의 통신 엔드 포인트는 큐 쌍 (760a-c)에 매핑될 수 있다. 이들 구현예들에서, 통신 엔드 포인트는 큐 쌍 번호에 의해 식별될 수 있다. 이들 구현예들에서, 큐 쌍 번호는 적어도 부분적으로, 유저 애플리케이션 (754)의 어드레스로서 사용될 수 있다.

가상 기계 (752)는 네트워크 (730)와 통신하기 위해 하나 이상의 가상 인터페이스들 (759a-b)을 추가로 할당받을 수 있다. 각각의 가상 인터페이스 (759a-b)는 IP 어드레스를 할당받을 수 있다. 일부 구현예들에서, 유저 애플리케이션 (754)은 네트워크 (730)와 통신하기 위해 하나 이상의 가상 인터페이스들 (759a-b)를 사용할 수 있다. 이들 구현예들에서, 유저 애플리케이션 (754)은 네트워크 (730)상에 프로세스들 및 다른 시스템에 대해 그 자체를 식별하기 위해 가상 인터페이스 (759a)의 IP 어드레스를 사용할 수 있다. 일부 구현예들에서, 유저 애플리케이션 (754)은 그 자체를 식별하기 위해 가상 인터페이스 (759a)에 할당된 IP 어드레스 및 통신 엔드 포인트 식별자 (예를 들어, 큐 쌍 번호)를 사용할 수 있다.

계속해서 도 7a에 대하여 설명된 예제, 해당 예제에서, 송신-측 유저 애플리케이션 (704a)은 큐 쌍 (710a)의 발송 큐 (712)에 메시지에 대하여 목적지 시스템 (718a)을 식별하는 정보와 함께 메시지를 둠으로써 메시지를 송신하였다. 네트워크 어댑터 디바이스는 이어서 발송 큐 (712)에 서비스를 제공할 수 있었고, 목적지 정보를 이용하여, 발송 메시지를 사용할 전송 컨텍스트 (716a)를 결정하였다. 네트워크 어댑터 디바이스는 그런다음, 전송 컨텍스트 (716a)를 이용하여, 메시지 송신을 위한 하나 이상의 패킷들을 생성하였다. 전송 컨텍스트 (716a)의 보조로, 네트워크 어댑터 디바이스는 그런 다음 다수의 연결들 (724a)을 이용하여 네트워크를 통하여 목적지 시스템 (718a)으로 패킷 또는 패킷들을 송신할 수 있다.

이 예제는 도 7b로 이어져서, 여기서 송신 시스템은 네트워크 상의 제 1 소스 시스템 (766a)로서 표현된다. 소스 시스템 (766a)으로부터 패킷 또는 패킷들은 다수의 경로들 (724a)를 이용하여 네트워크 (730)를 통하여 수신-측 시스템에 의해 수신된다. 일부 구현예들에서, 패킷들은 네트워크 어댑터 디바이스에 의해 수신된다. 이들 구현예들에서, 네트워크 어댑터 디바이스는 어느 전송 컨텍스트 (768a-b)가 패킷들에 대한 소스 시스템 (766a)에 대응하는지 결정할 수 있다. 네트워크 어댑터 디바이스는 적절한 전송 컨텍스트 (이 예에서 제 1 전송 컨텍스트 (768a)인) 위치를 찾기 위해서 목적지 어드레스 및/또는 패킷들에 제공된 소스 어드레스를 사용할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 소스 어드레스들을 함유하는 네트워크 어드레스 맵을 가질 수 있고, 네트워크 어댑터 디바이스는 전송 컨텍스트 (768a)를 발견하기 위해 소스 어드레스를 이용하여 네트워크 어드레스 맵 을 인덱싱할 수 있다.

일부 구현예들에서, 전송 컨텍스트들 (768a)은 신뢰할 수 있는 연결 전송에 유사한 전송 서비스들을 제공하도록 구성될 수 있다. 이들 구현예들에서, 네트워크 어댑터 디바이스는 신뢰할 수 있는 연결 전송들처럼 구성된 전송 컨텍스트들 (768a-b)의 테이블을 가질 수 있다. 네트워크 어댑터 디바이스는 추가로 테이블을 인덱싱하기 위해 목적지 큐 쌍 번호를 사용할 수 있고, 테이블은 적절한 전송 컨텍스트 (768a)를 표시할 수 있다. 일부 경우들에서, 네트워크 어댑터는 또한 올바른 전송 컨텍스트 (768a) 위치를 찾기 위해 착신 패킷들에 포함된 컨텍스트 식별자를 사용할 수 있다.

이하에서 더 상세하게 설명되는 것처럼, 전송 컨텍스트 (768a)는 소스 시스템 (766a)에 송신된 각각의 패킷이 수신되는 것을 보장하기 위해 각각의 패킷에 대한 상태를 모니터링할 수 있다. 전송 컨텍스트 (768a) (특별히 완화된 신뢰할 수 있는 데이터그램 전송 서비스)는 패킷들이 수신 시스템에서 순서에 맞게 수신되는지 여부를 추적하지 않을 수 있고, 일반적으로 모든 패킷들이 도달하는 것을 보장하는 것에만 관심이 있다. 전송 컨텍스트 (768a)는 일부 구현예들에서, 프로세스 착신 패킷들을 프로세스할 수 있고, 예를 들어, 네트워크 헤더들을 제거할 수 있다. 전송 컨텍스트 (768a)는 또한 복제 패킷들 (776)이 언제 수신되는지를 검출할 수 있다. 복제 패킷들 (776)은 네트워크 (730)에서 패킷이 드랍된 때 또는 드랍된 것처럼 보일 때 수신될 수 있다. 패킷이 네트워크 (730)에서 드랍된 것처럼 보일 때, 전송 컨텍스트 (768a)는 소스 시스템 (766a)이 패킷을 재발송할 것을 요청할 수 있다. 일부 경우들에서, 요청된 패킷은 예컨대 패킷이 실제로는 드랍되지 않았고, 하지만 도달하는데 예외적으로 오래 걸릴 때, 그래서 단지 드랍된 것처럼 보인 때 수신 시스템에 의해 두 번 이상 수신될 수 있다. 이것이 발생한 때, 전송 컨텍스트 (768a)는 제 1 복사본이 수신된 후에 수신된 임의의 추가의 복사본 (776)을 드랍할 수 있다.

네트워크 어댑터 디바이스는 전송 컨텍스트 (768a)로부터 (예를 들어, 펌웨어 또는 집적 회로를 이용하여) 패킷들을 수신할 수 있고 패킷들을 수신할 큐 쌍 (760a-c)을 결정할 수 있다. 네트워크 어댑터는 목적지 정보, 예컨대 적절한 큐 쌍 (760a)을 결정하기 위해서 착신 패킷들에 포함된 목적지 어드레스를 사용할 수 있다. 예를 들어, 목적지 어드레스는 적어도 부분적으로, 큐 쌍 번호를 포함할 수 있다. 네트워크 어댑터 디바이스는 실선 화살표 (772a)에 의해 표시된 것처럼 결정된 큐 쌍 (760a)의 수신 큐 (764)에 패킷 또는 패킷들을 둘 수 있다. 큐 쌍들 (760a-c)은 반드시 특정 전송 컨텍스트들 (768a-c)과 아니라 특정 통신 엔드 포인트들과 연관될 수 있다. 따라서, 특정 큐 쌍 (760a)은 파선 화살표 (772b)에 의해 표시된 상이한 전송 컨텍스트들로부터 패킷들을 수신할 수 있다.

수신 큐 (764)로부터, 네트워크 어댑터는 호스트 메모리 (780)에 버퍼들 (782)로 패킷들을 전송할 수 있다. 예를 들어, 네트워크 어댑터는 DMA 동작을 실행할 수 있고, 이는 전형적으로 호스트 메모리 (780)에 기록하기 위해서 호스트 디바이스 프로세서를 필요로 하지 않는다. 일부 구현예들에서, 가상 인터페이스 (759a)의 IP 어드레스 및/또는 통신 엔드 포인트의 아이덴티티 (이둘 중 하나 또는 둘 모두가 패킷에 대한 목적지 어드레스로서 제공될 수 있다)는 올바른 가상 기계 (752)로 패킷들을 전송하는 것을 보조할 수 있다. 일부 구현예들에서, 드라이버 프로그램 (758)은 패킷들을 버퍼들 (782)에 전송하는 것을 보조할 수 있다. 일부 구현예들에서, 표준 라이브러리는 이 보조를 제공할 수 있다.

유저 애플리케이션 (754)은 다수의 통신 엔드 포인트들을 사용하도록 구성될 수 있어서 다수의 큐 쌍들 (760a-c)에서 패킷들을 수신할 수 있다. 네트워크 어댑터 디바이스는 각각의 큐 쌍 (760a-c)에 할당된 우선권, 및/또는 서비스 레벨 계약에 따라 큐 쌍들 (760a-c)을 서비스할 수 있고 및/또는 큐 쌍들 (760a-c)이 타당하게 서비스하는 것을 보장할 수 있다.

일부 구현예들에서, 개별 버퍼들 (782)은 그것들이 이용 가능할 수 있는 어떤 순서로든 어떤 시간에든 채워질 수 있다. 패킷들은 또한 임의의 순서로 버퍼들 (782)에 놓여질 수 있다. 대부분의 경우들에서, 네트워크 어댑터는 최저 가능한 레이턴시 달성을 시도하기 위해 가능한 한 빠르게 큐 쌍들 (760a-c)로부터 호스트 메모리 (780)로 패킷들을 이동시키도록 구성될 수 있다. 이런 저런 이유들 때문에, 네트워크 어댑터는 전형적으로 또한 큐 쌍들 (760a-c)의 외부에 패킷들을 버퍼링하지 않는다. 때때로, 충분한 버퍼들 (782)이 이용 가능하지 않을 수 있다. 이것은 유저 애플리케이션 (754)이 충분한 버퍼들을 할당하지 않거나, 또는 충분히 빨리 버퍼들을 비우지 않기 때문에 발생할 수 있다. 이하에 추가로 설명될 것처럼, 이것이 발생한 때, 네트워크 어댑터는 유저 애플리케이션 (754)에 보낸 패킷들을 드랍하기 시작할 수 있고 패킷들이 드랍되고 있는 것을 유저 애플리케이션 (754)에 알릴 수 있다. 응답 메시지들은 패킷들이 드랍되고 있는 것을 소스 시스템에 알리기 위해 소스 시스템으로 거꾸로 발송될 수 있다. 일부 경우들에서, 소스 시스템은 이 특정 유저 애플리케이션 (754)에 패킷들을 전달하는 비율을 줄임으로써 응답할 수 있다. 일부 구현예들에서, 만일의 경우, 불충분한 버퍼 스페이스 및/또는 드랍된 패킷들에 대하여 무엇인가가 수행되어야 한다고 결정하는 것이 유저 애플리케이션 (754)에 맡겨진다.

앞에서 언급된 바와 같이, 패킷들은 임의의 순서로 버퍼들 (782)에 놓여질 수 있다. 일부 구현예들에서, 드라이버 프로그램 (758)은 패킷들을 그것들의 의도된 시퀀스로 배치하기 위해서 패킷들을 재순서화하는 책임이 있을 수 있다. 이들 구현예들에서, 드라이버 프로그램 (758)은 유저 애플리케이션 (754)에 순서대로 패킷들을 제공할 수 있고, 유저 애플리케이션 (754)은 패킷들이 순서가 바뀌어서 도달하였는지를 알 수 없다. 일부 구현예들에서, 유저 프로그램 (754)은 패킷들 그 자체를 재순서화할 수 있다. 어느 경우든, 유저 애플리케이션 (754) 및/또는 드라이버 프로그램 (758)은 호스트 디바이스에서 이용 가능한 더 높은 프로세싱 파워를 이용할 수 있다.

패킷 순서화를 보장하는 - 예컨대 신뢰할 수 있는 연결 및 신뢰할 수 있는 데이터그램 - 전송 서비스들에 비교하여, 완화된 신뢰할 수 있는 데이터그램 전송을 이용하는 시스템은 고성능 컴퓨팅 애플리케이션들에 더 나은 확장성 및 더 나은 레이턴시, 따라서 어쩌면 더 나은 성능을 제공할 수 있다. 예를 들어, 패킷 순서를 보장하는 전송 서비스들은 네트워크 어댑터 디바이스가 어떤 양의 패킷들을 버퍼핑하고 그런 다음 그것들을 호스트 디바이스에 제공하기 전에 그것들을 재순서화하는 것을 필요로 할 수 있다. 일부 경우들에서, 패킷들이 순서가 바뀌어서 도달한 때, 네트워크 어댑터 디바이스는 플로우내 모든 패킷들을 드랍하고 요청 플로우가 처음부터 재발송되도록 요청하는 것이 필요할 수 있다. 네트워크 어댑터 디바이스가 패킷들을 재순서화하면 호스트 디바이스 소프트웨어를 단순화할 수 있지만, 네트워크 어댑터에 대한 요건들은 더 복잡해질 수 있고, 패킷 전송 레이턴시 및 대역폭 소모를 증가시킬 수 있다.

그에 반해서, 완화된 신뢰할 수 있는 데이터그램 전송으로, 네트워크 어댑터 디바이스는 단지 최소 시간의 양동안 패킷들을 버퍼링할 수 있고, 따라서 아마 전체 레이턴시를 개선시킨다. 재순서화 동작(re-ordering operation)들이 그런 다음 호스트 디바이스상의 소프트웨어에 의해 수행될 수 있고, 여기서 소프트웨어는 레이턴시에 대한 최소한의 희생으로 강력한 호스트 디바이스 프로세서들을 사용할 수 있다. 완화된 신뢰할 수 있는 데이터그램 전송은 순서화를 보장하게 할 수 있지만, 그러나 그렇게 하는 것은 송신-측 큐 쌍들로부터 수신-측 큐 쌍들로 모든 플로우들에 대한 패킷 순서 상태를 추적하거나, 또는 상이한 로직 플로우들에 속하는 패킷들을 패킷들의 단일 시퀀스로 직렬화(serialize)하는 것을 요구할 것이다. 송신-측 큐 쌍들 및 수신-측 큐 쌍들의 모든 조합들간에 패킷 순서 상태 추적은 시스템이 스케일링하는 것을 어렵게 할 수 있다. 상이한 로직 플로우로부터 패킷들을 직렬화하는 것은 관련없는 플로우들간에 거짓 의존성(false dependency)을 생성할 수 있고, 평균 및 최대 패킷 전송 레이턴시를 증가시킬 수 있다. 그것처럼, 대부분의 경우들에서, 유저 애플리케이션들은 그것들 자체의 메시지 플로우의 추적을 유지할 것이고, 순서가 바뀌어서 도달하는 패킷들을 관리하기 위해 빠르게 재-구성될 수 있다. 완화된 신뢰할 수 있는 데이터그램 전송은 따라서 패킷 순서화를 호스트 디바이스 소프트웨어에 맡길 수 있고, 모든 패킷들이 전달되는 것을 보장하는데 중점을 둘 수 있다.

앞에서 논의된 것처럼, 전형적인 컴퓨팅 클러스터 시스템에서 소스 시스템으로부터 목적지 시스템으로 네트워크를 걸쳐 이동하기 위해 패킷들이 취할 수 있는 다수의 경로들이 있을 수 있다. 하나의 소스로부터 하나의 목적지로 패킷들의 스트림은 패킷들의 플로우 또는, 보다 단순하게, 플로우(flow)로 불리울 수 있다. 플로우내 패킷들은 서로 연관될 수 있고 (예를 들어, 그것들은 데이터, 예컨대 비디오 또는 대화의 하나의 연속 스트림에 속한다), 플로우가 끝나고 다시 시작할 수 있다(예를 들어, 비디오 또는 대화가 끝날 수 있고, 새로운 하나가 시작될 수 있다). 앞에서도 언급한 바와 같이, 클러스터에 걸친 더 큰 효율은 소정의 소스로부터 특정 목적지로 패킷들이 모든 이용 가능한 경로들에 걸쳐 분산될 때 달성될 수 있다. 그러나, 현존하는 전송 서비스들은 전형적으로 순서에 맞는 패킷 전달을 위해 디자인되고, 순서에 맞는 패킷 도달의 확률을 보장하고 성능저하를 줄이기 위해 단지 하나의 경로를 이용하여 하나의 플로우를 발송하도록 구성될 수 있다. 더욱이, 이들 전송 서비스들은 전형적으로 하나의 플로우가 끝나고 다른 플로우가 시작할 때만 경로들을 바꿀 수 있다.

도 8 은 이용 가능한 경로들(840)에 걸쳐 더 큰 이용율(untilization)을 달성하기 위해 완화된 신뢰할 수 있는 데이터그램 전송이 어떻게 네트워크(830)에 걸친 다수의 경로들(840)을 관리할 수 있는지의 예를 예시한다. 도 8의 예제에서, 소스 시스템 (802)으로부터 목적지 시스템 (852)으로의 패킷들의 플로우 (810)는 패킷들의 그룹들로 분할될 수 있고, 이는 “플로릿들(flowlets)” (800)로 지칭될 수 있다. 소스 전송 컨텍스트 (816) 및 대응하는 목적지 전송 컨텍스트 (868)은 네트워크 (830)에 걸친 경로들 설정 및 해지를 포함하여 플로릿들 (800)의 송신 및 수신을 관리할 수 있다. 소스 및 목적지 컨텍스트들 (816,868)은 또한 각-플로릿 (800) 베이시스에 기초하여 패킷들의 상태를 모니터링할 수 있다. 각각의 플로릿 (800)은 상이한 경로 (840)를 이용하여 송신될 수 있고, 하나의 플로릿 (800)내 모든 패킷들은 동일한 경로를 이용한다. 일부 구현예들에서, 모든 패킷들이 소스 시스템 (802)으로부터 하나의 포트 (822)를 이용하여 송신되고, 하나의 포트 (862)에 목적지 시스템 (852)에서 수신된다. 다른 구현예들에서, 소스 시스템 (802) 및/또는 목적지 시스템 (852)은 네트워크 (830)에 연결된 다수의 포트들을 가질 수 있다.

앞에서 논의된 것처럼, 완화된 신뢰할 수 있는 데이터그램 전송 구현예에서, 소스 컨텍스트 (816)는 전형적으로 하나의, 특정 목적지 컨텍스트 (868)와 연관된다. 소스 컨텍스트 (816)는 대부분의 경우들에서 목적지 시스템 (852)과 연관된 어드레스에 의해 식별된다. 이 목적지 어드레스는 목적지 컨텍스트 (868)에 할당될 것이다. 유사하게, 목적지 컨텍스트 (868)는 소스 컨텍스트 (816)에 할당된 소스 시스템 (802)에서의 어드레스에 의해 식별될 수 있다. 소스 컨텍스트 (816)는 패킷들의 플로우 (810)의 송신을 관리할 수 있고, 이는 소스 시스템 (802)에서 운영하는 다수의 유저 애플리케이션들로부터의 패킷들을 포함할 수 있다. 플로우 (810)내 패킷들은 모든 목적지 시스템 (852)상에서 운영하는 유저 애플리케이션들을 향할 것이다. 목적지 컨텍스트 (868)는 목적지 시스템 (852)에서 플로우 (810)내 패킷들의 수신을 관리할 수 있다.

일부 구현예들에서, 소스 시스템 (802)은 목적지 컨텍스트 (868)와 연관된 어드레스가 처음으로 매핑된 때 (예를 들어, 도면들 5a-5b의 예에 따라) 새로운 플로릿 (800)을 개시할 수 있다. 일단 도 8의 예제에서 제 1 플로릿 (800)이 초기화된 후에, 추가 플로릿들 (800)이 수립될 수 있다. 연결 수립 메시지들이 정상 네트워크 트래픽에 부착될 수 있고, 전형적으로 목적지 시스템 (852)에 연결 요청을 발송하는 소스 시스템 (802), 및 소스 시스템 (802)으로 다시 확인 응답 메시지를 발송함으로써 응답하는 목적지 시스템 (852)을 포함한다. 일부 구현예들에서, 플로릿들 (800)은 이 예에서처럼 단방향이고, 여기서 플로릿들 (800)은 소스 시스템 (802)에서 발원하고 목적지 시스템 (852)에서 종료된다. 동일한 소스 컨텍스트 (816) 및 목적지 컨텍스트 (868)이 목적지 시스템 (852)에 발원하고 소스 시스템 (802)에서 끝나는 플로릿들을 수립하기 위해 사용될 수 있지만, 그러나 일부 구현예들에서 이들은 도 8의 예제에 예시된 것과 상이한 셋의 플로릿들일 것이고, 별도로 관리될 것이다.

도 8의 예제는 예시의 방식으로 네 개의 플로릿들 (800)을 예시한다. 다양한 구현예들에서, 더 많거나 또는 더 적은 플로릿들 (800)이 전송 컨텍스트들 (816,868)에 의해 사용될 수 있다. 일부 구현예들에서, 소스 시스템 (802)과 목적지 시스템 (852) 간의 플로릿들 (800)의 수는 구성 가능할 수 있고, 및/또는 두개의 시스템들 (802,852) 간에 이용 가능한 경로들 (840)의 수에 의해서만 제한될 수 있다.

전형적으로, 플로릿들 (800)은 단지 전송 컨텍스트들 (816,868)에 알려지고, 큐 쌍들, 가상 기계들, 또는 유저 애플리케이션들과는 무관하다. 달리 말하면, 소스 시스템 (802) 및 목적지 시스템 (852)상에서 운용하는 유저 애플리케이션들은 플로릿들 (800)을 알지 못하고, 대부분의 구현예들에서, 표준 라이브러리들 및/또는 드라이버 프로그램들과만 상호작용한다. 다양한 소스들로부터의 패킷들은 패킷들이 동일한 목적지 시스템 (852)에 어드레스 지정된 때 동일한 플로우 (810)에 놓여질 수 있다. 패킷들이 플로릿들 (800)에 걸쳐 고르게 분배되도록 플로우 (810)로부터의 패킷들은 플로릿들 (800)에 할당될 수 있다. 대안적으로 또는 추가적으로, 패킷들을 적게 운용하는 플로릿들 (800)이 먼저 할당되도록 패킷들이 할당될 수 있다. 작고 빠르게 운용하는 플로릿들 (800)은 더 빠른 경로들을 이용할 수 있고 따라서 패킷들을 이들 플로릿들 (800)에 할당하는 것이 전체 활용 및 스루풋을 개선시킬 수 있다.

소스 컨텍스트 (816)은 각-플로릿 (800) 베이시스에 기초하여 패킷들을 추적할 수 있다. 각각의 플로릿 (800)은 패킷 시퀀스 번호를 유지할 수 있고, 플로우 (810)로부터 패킷들이 플로릿 (800)에 할당될 때 각각의 패킷은 또한 해당 플로릿 (800)에 대한 다음 패킷 시퀀스 번호에 할당될 수 있다. 패킷들은 또한 각각의 패킷의 플로릿 (800)을 식별하기 위해 목적지 컨텍스트 (868)에 의해 사용될 수 있는 플로릿 식별자를 할당받을 수 있다.

각각의 플로릿 (800)에 대하여, 소스 시스템 (802)은 플로릿 (800)에 할당된 각각의 패킷에 대한 상태 정보(status information) (820)를 유지할 수 있다. 상태 정보 (820)는 패킷을 재송신하는데 필요로 될 수 있는 임의의 정보 및 각각의 패킷의 패킷 시퀀스 번호를 포함할 수 있다. 대부분의 경우들에서, 상태 정보 (820)는 시간 패킷이 송신된 시간으로부터 소스 시스템 (802)이 패킷이 수신되었다는 확인 응받을 수신할 때까지 패킷에 대하여 유지될 수 있다. 소스 컨텍스트 (816)는 플로릿 (800) 마다 단지 제한된 수의 아직 처리되지 않은 패킷들에 대한 상태 정보 (820)를 유지할 수 있다. 예를 들어, 소스 컨텍스트 (802)는 각 플로릿 (800)마다 32 아직 처리되지 않은 패킷들만을 허용하도록 구성될 수 있다. 플로릿 (800)마다의 아직 처리되지 않은 패킷들의 수는 고정될 수 있거나 또는 구성 가능할 수 있다. 플로릿 (800)이 매우 느릴 때- 즉, 확인 응답들이 느리게 도달하거나, 또는 전혀 도달하지 못하는 때- 소스 컨텍스트 (802)는 플로릿 (800)을 다른 경로 (840)로 이동시킬 수 있다.

목적지 컨텍스트 (868)는 그것 자체의 상태 정보 (860)로 각-플로릿 (800) 베이시스상의 패킷들을 또한 추적할 수 있다. 목적지 컨텍스트 (868)에 의해 유지되는 상태 정보 (860)는 각각의 플로릿 (800)에 대한 패킷 시퀀스 번호들을 또한 포함할 수 있다. 이하에 상세하게 설명될, 목적지 컨텍스트 (868)가 소스 시스템 (802)에 송신되는 확인 응답들을 생성하기 위해 상태 정보 (860)를 사용할 수 있다. 확인 응답들은 특정 플로우에 대한 패킷들이 목적지 시스템 (852)에 도달하였다는 것을 소스 컨텍스트 (802)에 알릴 수 있고, 전형적으로 어느 패킷들이 도달하였는지를 표시할 수 있다.

플로릿들 (800)은 활성(active) 또는 유휴상태(idle) 일 수 있다. 활성 플로릿들 (800)은 아직 처리되지 않은 패킷들, 즉, 발송되었지만 그러나 아직 확인 응답되지 않는 패킷들을 갖는다. 유휴상태 플로릿들 (800)은 아직 처리되지 않은 패킷들이 없고, 또한 발송될 것을 대기하는 패킷들도 없다. 플로릿 (800)이 유휴상태일 때, 소스 컨텍스트 (816)는 플로릿 (800)을 상이한 경로 (840)로 이동시킬 것을 결정할 수 있다. 일반적으로, 유휴상태 플로릿 (800)을 다른 경로로 이동시키는 소스 컨텍스트의 (816) 결정은 체계적이라기보다는 (예를 들어, 고정된 시간들에서 또는 플로릿 (800)이 유휴상태가 될 때마다) 랜덤 베이시스에 기초하여 이루어진다. 유휴상태 플로릿들 (800)을 다른 경로들로 이동시키는 것은 소스 컨텍스트 (816)가 네트워크 (830)에 걸쳐 덜 바쁜 경로들 (840)을 찾으려는 것을 허용할 수 있다.

각각의 플로릿 (800)로부터 패킷들은 그것들의 패킷 시퀀스 번호들의 순서에 따라 소스 시스템 (802)에 의해 송신될 수 있다. 플로릿 (800)로부터 발송된 제 1 패킷은 특정 플로릿 (800)이 시작된다는 것을 목적지 컨텍스트 (868)에 알리기 위한 “시퀀스의 시작(start-of-sequence)” 표시자를 또한 포함할 수 있다. 목적지 컨텍스트 (868)는 그런 다음 해당 플로릿 (800)에 대한 상태를 수립하기 위해 시퀀스의 시작 표시자로 패킷내 패킷 시퀀스 번호를 사용할 수 있다. 목적지 컨텍스트 (868)는 이어서 해당 플로릿 (800)에 대한 패킷들이 그것들의 패킷 시퀀스 번호들의 순서대로 도달하는 것을 기대한다. 따라서, 예를 들어, 하나의 플로릿 (800)로부터의 패킷들은 시퀀스 번호들 “1, 2, 3, 4, 5...”를 갖고 소스 시스템 (802)에 의해 송신될 수 있고 제 1 패킷은 시퀀스의 시작 표시자를 포함한다. 목적지 시스템 (852)은 시퀀스의 시작 표시자의 노트(note)를 갖는 제 1 패킷을 수신할 수 있고, 이어서 해당 플로릿 (800)이, 해당 순서로 도달하도록 시퀀스 번호들 “2, 3, 4, 5…”을 갖는 패킷들을 기대한다.

그러나, 패킷들은 네트워크 (830)에서 드랍될 수 있고, 목적지 시스템 (852)에 결코 도달할 수 없다. 예를 들어, 상기에서 제공된 예제로 계속해서, 목적지 시스템은 패킷 시퀀스 번호들 “1, 3”을 갖는 패킷들을 수신할 수 있고 이는 패킷 시퀀스 번호 “2”를 갖는 패킷이 드랍되었다는 것을 나타낸다. 설명될 이하에서 더 상세하게, 소스 컨텍스트 (816) 및 목적지 컨텍스트 (868) 둘 모두에 의해 유지되는 패킷 상태는 컨텍스트들 (816,868)이 패킷들이 네트워크 (830)에서 드랍된 때를 식별하는 것을, 손실된 임의의 패킷들을 재송신하는 것을 가능하게 할 수 있다.

네트워크 (830)내 링크들의 과잉 사용에 의해 야기되는 느려짐(slowness) 및 네트워크 (830)내 드랍들은 성능에 영향을 미칠 수 있고 따라서 전형적으로 양쪽을 피하거나 또는 최소화하는 것이 바람직하다. 소스 컨텍스트 (816)는 많은 방식들로 하나의 경로 (840)를 따라서의 과잉 드랍들 또는 혼잡(congestion)을 검출할 수 있다. 예를 들어, 플로릿 (800)에 대한 상태 정보 (820)는 소스 컨텍스트 (816)가 패킷이 송신된 때와 패킷이 수신되었다고 확인 응답한 때 사이의 시간을 결정하기 위해 사용할 수 있는 타이머(timer)를 포함할 수 있다. 긴 시간 기간은 플로릿 (800)에 의해 사용되는 경로를 따라서의 혼잡을 표시할 수 있다. 대안적으로 또는 추가적으로, 소스 컨텍스트 (816)는 패킷들을 각각의 플로릿 (800)에 얼마나 빨리 추가할 수 있는지를 추적할 수 있다. 다른 플로릿들 (800)만큼 빠르게 패킷들을 수용할 수 없는 플로릿 (800)은 네트워크에 걸쳐 그것의 경로(840)를 따라서 혼잡을 겪을 수 있고, 및/또는 과잉 드랍들을 겪을 수 있다. 대안적으로 또는 추가적으로, 소스 컨텍스트 (816)는 특정 플로릿 (800)에 대하여 큰 수의 재송신 요청들을 수신할 수 있고, 이는 플로릿 (800)이 이용하는 경로를 따라서 과잉 드랍들을 표시할 수 있다.

플로릿 (800)이 혼잡 또는 과잉 드랍들을 겪고 있을 수 있다고 소스 컨텍스트 (816)가 결정하면, 소스 컨텍스트 (816)는 플로릿 (800)을 다른 경로 (840)로 이동시킬 수 있다. 일부 구현예들에서, 일단 플로릿 (800)이 이동된 후에, 설사 경로 식별자가 이제 바뀌었다 할지라도 목적지 컨텍스트 (852)는 플로릿 (800)으로부터 패킷들을 계속 수신하고 수락할 것이다. 일부 구현예들에서, 소스 컨텍스트 (816)는 재위치된 플로릿 (800)이 가장 오래된 확인 응답되지 않은 패킷 시퀀스 번호를 갖는 패킷과 함께 새로운 시퀀스의 시작 표시자를 발송하게 할 수 있다. 이들 구현예들에서, 새로운 시퀀스의 시작 표시자의 수신시에, 목적지 컨텍스트 (868)는 소스 시스템 (802)이 새로운 시퀀스의 시작 표시자를 갖는 패킷 이전에 발송된 임의의 패킷들을 포기하였고, 재시작된 플로릿 (800)에 대하여 가졌던 임의의 정보 (예를 들어, 패킷 시퀀스 번호들)를 폐기한다는 것을 추정할 수 있다.

일부 경우들에서, 목적지 컨텍스트 (868)는 순서가 바뀌어서 도달된 패킷내 시퀀스의 시작 표시자를 수신할 수 있다. 예를 들어, 목적지 컨텍스트 (868)는 시퀀스 번호들 “1, 2, 3, 1”을 갖는 패킷들을 수신할 수 있고 여기서 시퀀스 번호 “1”을 갖는 둘 모두의 패킷들은 동일한 패킷의 복사본들이고, 시퀀스의 시작 표시자를 갖는다. 이것은 예를 들어, 플로릿의 (800) 경로 (840)가 아주 느리고, 시퀀스 번호 “1”을 갖는 제 1 패킷에 대한 확인 응답이 소스 시스템 (802)에 도달하는 것이 너무 느린 때 발생할 수 있다. 이 느려짐 때문에, 소스 시스템 (802)은 확인 응답 수신전에 스위치된 경로들 및 재시작된 플로릿 (800)을 가질 수 있다. 이 상황에서, 목적지 컨텍스트 (868)는 패킷 시퀀스 번호 “1”을 갖는 제 2 패킷 수신시에 플로릿 (800) 상태를 리셋(reset)할 필요가 없다는 것을 인식할 수 있다. 대신에, 목적지 컨텍스트 (868)는 시퀀스의 시작으로서 패킷 시퀀스 번호 “1”을 갖는 제 1 패킷을 인식할 수 있고, 패킷 시퀀스 번호 “1” 및 시퀀스의 시작 표시자 세트를 갖고 도달한 임의의 추가의 패킷들을 무시할 수 있다. 일부 구현예들에서, 목적지 컨텍스트 (868)는 추가 패킷들이 수락되지 않았다는 것을 나타내는 확인 응답을 발송할 수 있고, 이는 상황을 이해하는데 소스 컨텍스트 (816)를 보조할 수 있다.

플로릿들 (800)은 또한 소스 시스템 (802) 또는 목적지 시스템 (852)이 연결 차단된 때 재시작될 것을 필요로 할 수 있다. 목적지 시스템 (852)은 완전히 또는 단지 부분적으로 연결 차단될 수 있다. 완전한 연결 차단(full disconnect)은 목적지 시스템 (852)이 리셋될 때 발생할 수 있다. 목적지 시스템 (852)이 리셋 후에 동작하면, 목적지 컨텍스트 (868)는 패킷들을 수신할 수 있지만, 그러나 그것의 상태 정보 (860)가 리셋되기 때문에, 목적지 컨텍스트 (868)는 임의의 플로릿들 (800)에 대한 상태 정보(예를 들어, 도달된 패킷들에 대한 시퀀스 번호들)를 가질 수 없다. 목적지 컨텍스트 (868)는 따라서, 모든 수신된 패킷들에 대하여, 패킷들이 수락되지 않은 것을 나타내는 응답들을 발송할 수 있다. 일부 경우들에서, 응답들은 목적지 컨텍스트 (868)가 그것이 기대하지 않은 패킷 시퀀스 번호들을 수신하였다는 것을 소스 컨텍스트 (816)에 알리는 표시자를 포함할 수 있다. 이들 응답들의 수신시에, 소스 컨텍스트 (816)는 목적지 컨텍스트 (852)가 연결 상태의 추적을 상실하였다는 것을 이들 패킷들을 발송하려고 한 유저 애플리케이션에 통지할 수 있다. 이것은 유저 애플리케이션이 복원 동작들을 개시하게 할 수 있다.

목적지 시스템 (852)에서 부분적 연결 차단이 또한 발생할 수 있다. 부분적 연결 차단은 예를 들어, 플로우 (810)를 수신하는 목적지 시스템 (852)에서 가상 기계가 그것이 죽었기 때문에 또는 그것이 셧 다운 되었기 때문에 오프라인(offline)으로 갈 때 일어날 수 있다. 일부 구현예들에서, 소스 컨텍스트 (816)는 명백하게 예를 들어 제어 평면상에서 수신된 명령을 통하여 그것의 타겟 가상 기계가 오프라인인 것을 명확하게 알게 될 수 있다. 다른 구현예들에서, 소스 컨텍스트 (816)는 아직 처리되지 않은 패킷들이 미리 결정된 시간 기간 (예를 들어, 타이머의 만료시에)동안 확인 응답되지 않은 때 타겟 가상 기계가 오프라인이라고 결정할 수 있다. 타겟 가상 기계가 오프라인인 것을 결정한 때, 또는 알려진 때, 소스 컨텍스트 (816)는 임의의 아직 처리되지 않은 패킷들을 드랍할 수 있고 목적지 시스템 (852) 과의 그것의 연결을 폐쇄할 수 있다. 일부 구현예들에서, 소스 컨텍스트 (816)는 또한 드랍된 패킷들이 발송되지 않는 것을 소스-측 유저 애플리케이션들에 보고할 수 있다. 타겟 가상 기계가 오프라인이기 때문에, 소스 컨텍스트 (816)는 또한 플로우 (810)로부터 패킷들을 송신하기 위한 임의의 후속 요청들을 거부할 수 있다. 타겟 가상 기계가 결국에 백업(back up)될 수 있고 해당 시간에 소스 컨텍스트 (816)는 타겟 가상 기계가 다시 살아난 것을 알게 될 수 있다. 소스 컨텍스트 (816)는 그런 다음 목적지 시스템 (852)과의 그것의 연결을 재시작할 수 있고, 플로우 (810)로부터 패킷들을 다시 수락하기 작한다.

부분적 연결 차단은 예를 들어, 플로우 (810)로부터 패킷들을 수신하는 목적지 시스템 (852)에서 유저 애플리케이션이 오프라인으로 간 때 또한 발생할 수 있다. 목적지-측 유저 애플리케이션은 갑자기 고장 나거나(crashed) 또는 폐쇄될 수 있다. 이 상황에서, 목적지 컨텍스트 (868)는 평상시대로 착신 패킷들에 확인 응답할 수 있고, 현재 오프라인 목적지-측 유저 애플리케이션에 할당된 수신 큐에 그것들을 전달할 수 있다. 패킷들은 그런 다음 수신 큐에서 드랍될 수 있다. 목적지 컨텍스트 (868)는 대부분의 경우들에서, 임의의 플로릿들 (800)이 리셋되지 않을 것인 데 왜냐하면, 많은 경우들에서, 플로릿들은 오프라인 유저 애플리케이션을 포함하여 다수의 목적지-측 유저 애플리케이션들에 보내진 패킷들을 포함할 수 있기 때문이다. 대신에, 일부 구현예들에서, 목적지 컨텍스트 (868)는 오프라인 유저 애플리케이션에 보내진 패킷들을 수신된 것으로 처리할 것이고, 무엇을 해야할 지를 알아내기 위해서 소스 (802) 및 목적지 (852) 시스템들에서 유저 애플리케이션들에 그것을 맡길 것이다. 다른 구현예들에서, 패킷들은 드랍될 것이고 송신 유저 애플리케이션은 드랍된 패킷들을 알게될 것이다.

소스 시스템 (802)은 또한 완전히 연결 차단 (예를 들어, 리셋됨으로써) 또는 부분적으로 연결 차단될 수 있다. 소스-측 유저 애플리케이션이 재시작된 때 야기되는 부분적 연결 차단은 소스 컨텍스트 (816)상에 아무런 영향이 없을 수 있다. 소스-측 가상 기계 재시작에 의해, 또는 전체 소스 시스템 (802)의 리셋에 의해 야기되는 부분적 연결 차단은 소스 컨텍스트 (816)가 재시작되는 것으로 귀결될 수 있다. 이들 경우들에서, 소스 컨텍스트 (816)는 소스 시스템 (802)이 먼저 부트된 때와 동일한 방식으로 그것의 플로릿들 (800)을 재시작할 수 있다. 소스 시스템 (802)에서, 새롭게 시작된 플로릿 (800)은 전형적으로 이력(history) (예를 들어, 알려진 어떠한 패킷 시퀀스 번호들도 없는)을 가지지 않는다. 따라서, 일부 구현예들에서, 소스 컨텍스트 (816)는 시퀀스의 시작 표시자를 갖는 패킷을 발송한 후에 시퀀스의 시작 표시자를 갖는 패킷이 목적지 시스템 (852)에 의해 확인 응답될 때 까지 패킷들을 발송하는 것을 지연할 수 있다. 그렇게 하는 것은 플로릿 (800)에 대하여 “가장 최근에 확인 응답된(most recently acknowledged)” 패킷 시퀀스 번호를 수립할 수 있다. 일부 경우들에서, 소스 컨텍스트 (816)는 시퀀스의 시작 표시자를 갖는 최초 패킷이 목적지 시스템 (852)에 의해 수락되지 않은 것을 나타내는 확인 응답을 수신할 수 있다. 이것은 예를 들어, 목적지 컨텍스트 (868)가 최초 패킷에 포함된 패킷 시퀀스 번호를 거부한 때 발생할 수 있다. 이것이 발생한 때, 소스 컨텍스트 (816)는 시퀀스의 시작 표시자를 갖는 패킷을 다시 발송할 수 있고, 일부 구현예들에서, 상이한 시작 패킷 시퀀스 번호를 갖는 패킷을 제공할 수 있다.

네트워크 (830)내 패킷 드랍들, 경로 (840) 스위칭, 연결 차단, 및 플로릿 재시작들은 패킷들이 재발송되는 것을 필요로 하는 것을 각각 초래할 수 있다. 목적지 시스템 (852)에서 수신된 때, 이들 재발송된 패킷들은 앞서 수신된 패킷들과 시퀀스가 다를 것이다. 예를 들어, 목적지 컨텍스트 (868)는 시퀀스 번호들 “1, 3”를 갖는 패킷들을 수신하였을 수 있고 따라서 시퀀스 번호 “2”를 갖는 패킷이 재발송될 필요가 있다는 것을 표시할 수 있다. 일단 시퀀스 번호 “2”를 갖는 패킷이 재발송된 후에, 목적지 컨텍스트 (868)는 이 특정 플로릿 (800)에 대하여 시퀀스 번호들 “1, 3, 2”를 가질 것이다.

아래에 더 상세하게 설명될 것처럼, 목적지 컨텍스트 (868)는 이런 식으로 패킷들이 순서가 바뀌어서 도달하는 것을 기대하도록 구성될 수 있다. 소스 컨텍스트 (816)과 협력하는 목적지 컨텍스트 (868)는 대부분의 구현예들에서 모든 패킷들이 수신되는 것을 보장하고, 전형적으로 해당 패킷들이 수신된 순서는 고려하지 않는다. 목적지 컨텍스트 (868)는 전형적으로 포워드들 패킷들을 패킷들이 수신되자 마자, 또는 실제로 가능한 한 빨리 목적지-측 호스트 디바이스로 포워딩하고, 임의의 요구된 패킷들의 재순서화는 호스트 디바이스에 맡겨진다. 패킷들은 그것들이 플로우 (810)의 소스 단에서 있었던 순서와는 다른 순서로 플로우(810)의 목적지 단에 있을 수 있다는 것에 유의하여야 한다. 그러나, 일단 패킷들이 그것들의 타겟 큐 쌍들에 전달된 후에, 특정 목적지-측 유저 애플리케이션 행인 패킷들은 실제로 순서에 맞게 있을 수 있다. 그러나, 큐 쌍에서 순서화(ordering)는 목적지 컨텍스트 (868)에 의해 보장되지 않는다.

상기에서 논의된 바와 같이, 소스 컨텍스트 (816) 및 목적지 컨텍스트 (868)는 각각의 개별 플로릿 (800)에 대하여 상태 정보 (820,860)를 각각 유지할 수 있다. 상태 정보 (820,860)를 이용하여, 소스 및 목적지 컨텍스트 (816, 868)는 플로우 (810)내 모든 패킷이 목적지 시스템 (852)에 도달하는 것을 보장할 수 있다.

도면들 9a-9b는 완화된 신뢰할 수 있는 데이터그램 전송이 어떻게 신뢰할 수 있는 패킷들의 전달을 보장할 수 있는지의 예를 예시한다. 완화된 신뢰할 수 있는 데이터그램 전송 서비스는 송신-측 (900) 컨텍스트가 각각의 송신된 패킷에 대한 상태 정보를 유지하게 함으로써, 수신-측 (950) 컨텍스트가 수신-측이 수신한 모든 패킷에 대하여 송신 측 (900)에 응답들을 리턴하게 함으로써 보장된 패킷들의 전달을 제공할 수 있다. 도 9a는 송신-측 (900) 컨텍스트가 각각의 송신된 패킷에 대하여 상태 정보를 어떻게 유지할 수 있는지의 예를 예시한다. 도 9b는 수신-측 (950) 컨텍스트가 상태 정보를 어떻게 유지할 수 있는지 및 응답들을 생성하기 위해 상태 정보를 어떻게 사용하는 지의 예를 예시한다.

일반적으로, 유저 애플리케이션들은 일반적으로 패킷들이 그것들의 목적지에 도달한 것을 보장하는 것을 수반하지 않는다. 수신-측 유저 애플리케이션이 하나 이상의 패킷들이 네트워크에서 드랍된 지를 결정하기 위해서, 수신된 패킷들은 수신-측 전송 스택에 끝까지 유저 애플리케이션으로 이동하여야 할 것이다. 이를 따라서, 예를 들어, 만약 유저 애플리케이션이 너무 바빠서 그것을 수신할 수 없으면 패킷들이 지연될 수 있다. 유저 애플리케이션은 그런 다음 전송 스택을 전부 내려와서, 네트워크를 걸쳐서, 그런 다음 송신-측 전송 스택에 송신 유저 애플리케이션으로 요청들을 재송신하여야 할 것이다. 그에 반해서, 수신-측 전송 컨텍스트는 패킷들에 대하여 수신 측에서 가장 빠른 컨택 포인트일 수 있고, 따라서 패킷들이 도달하지 않은 때를 보다 빠르게 결정할 수 있다. 유사하게, 송신-측 전송 컨텍스트는 재-송신 요청들을 처음에 수신할 수 있고, 따라서 유저 애플리케이션보다 훨씬 더 빠르게 요청을 재송신하도록 응답할 수 있다.

일부 구현예들에서, 완화된 신뢰할 수 있는 데이터그램 전송 서비스는 패킷 시퀀스 번호들을 이용하여 패킷들의 보장된 신뢰할 수 있는 전달을 제공할 수 있다. 송신-측 (900) 전송 컨텍스트는 송신된 각각의 패킷에 대하여 각-플로릿 베이시스마다 패킷 시퀀스 번호들의 추적을 유지할 수 있다. 수신-측 (950) 전송 컨텍스트는 수신된 패킷들에 대한 패킷 시퀀스 번호들의 추적을 유지할 수 있고, 송신-측 (900) 전송 컨텍스트로 응답들을 거꾸로 발송한다. 응답들은 어느 패킷들이 수신되었는지를 송신-측 (900) 전송 컨텍스트에 통지할 수 있다. 구체적으로, 수신-측 (950) 전송 컨텍스트가 그것들의 패킷 시퀀스 번호들에 대하여 순서에 맞게 패킷 시퀀스 번호들을 갖는 패킷들을 수신한 때, 수신-측 (950) 전송 컨텍스트는 “ACK” 응답을 발송할 수 있다. 수신-측 (950) 전송 컨텍스트가 그것들의 패킷 시퀀스 번호들에 대한 응답으로 순서가 바뀐 패킷들을 수신한 때, 수신-측 (950) 전송 컨텍스트는 “선택적(selective)-ACK” 또는 "SACK" 응답을 발송할 수 있다. 간헐적으로, 패킷은 수신-측 (950) 전송 컨텍스트에 도달할 수 있지만, 수신-측 (950) 전송 컨텍스트가 패킷을 수락할 수 없을 수 있다. 이 상황에서, 수신-측 (950) 전송 컨텍스트는 패킷이 수락되지 않았다는 것을 송신-측 (900) 전송 컨텍스트에 표시하기 위해 “NACK”를 발송할 수 있다.

도 9a는 응답들의 수신 및 아직 처리되지 않은 패킷들의 송신-측 (900) 관리의 예를 예시한다. 도 9a의 예는 예로서, 세 개의 플로릿(flowlet)들 (904a-c)을 예시한다. 앞에서 논의된 것처럼, 플로릿들의 세트는 일반적으로 하나의 패킷 플로우로부터의 패킷들을 포함하지만, 그러나 플로우는 동일한 목적지 시스템으로 송신되는 다수의 유저 애플리케이션들 (902)로부터의 패킷들을 포함할 수 있다. 패킷 플로우는 그룹들 (대부분의 구현예들에서, 서로에 관한 패킷들의 관계에 대한 관심 없이)로 분할될 수 있고, 패킷들의 이들 그룹들은 서브-플로우들 또는 플로릿들로 지칭될 수 있다. 특정 플로릿내 패킷들은 일반적으로 경로가 송신-측 (900) 전송 컨텍스트에 의해 변경되지 않는 한 또는 변경될 때까지 네트워크(930)를 통하여 동일한 경로를 이용한다. 도 9a의 간략화된 예제는 각 플로릿 (904a-c)마다 단지 네 개의 패킷들을 예시하고, 각각의 플로릿 (904a-c)은 네 개보다 더 많은 아직 처리되지 않은 패킷들에 대한 상태 정보를 유지할 수 있다는 것이 이해되어야 한다. 일부 구현예들에서, 플로릿이 상태를 유지할 수 있는 패킷들의 수는 제한된다 (예를 들어, 8, 16, 13 또는 그 이상 패킷들까지). 이들 구현예들에서, 아직 처리되지 않은 패킷들의 수가 한계치와 같으면, 아직 처리되지 않은 패킷 중 적어도 하나가 수신된 것으로 확인 응답될 때까지 해당 플로릿을 이용하여 더 이상의 패킷들이 발송될 수 없다.

제 1 예 플로릿 (904a)에 대하여, 제1 세 개의 패킷들 (908a), (908b), (908c)이 네트워크 (930)으로 발송되었고, 제 4 패킷 (908d)이 송신될 것을 대기하고 있다. 제 1 플로릿 (904a)에 대한 상태 정보 (906a)는 제 1 패킷 (908a)에 대하여 ACK 상태 (910a) 및 제 2 패킷 (908b)에 대하여 ACK 상태 (910b)를 나타낸다. 이들 두개의 ACKS 상태들 (910a), (910b)은 제 1 (908a) 및 제 2 (908b) 패킷들이 수신-측 (950) 전송 컨텍스트에서 수신되었고, 그것들은 순서에 맞게 (예를 들어, 제 1 패킷 (908a)이 수신되고, 이어 제 2 패킷 (908b)가 수신되고) 수신된 것을 표시한다. 일부 구현예들에서, 송신-측 (900) 전송 컨텍스트는 가장 오래된 확인 응답되지 않은 패킷을 기억하는 것만이 필요한데, 왜냐하면 임의의 순서 패킷들을 재송신하기 위한 요청들이 도달하지 않을 것이기 때문이다. 이들 구현예들에서, 송신-측 (900) 전송 컨텍스트는 따라서 제 1 (908a), 및 아마 또한 제 2 (908b), 패킷에 대하여 상태 정보 (906a)에 대하여 잊어버릴 수 있다. 플로릿에 패킷들의 수가 제한되는 구현예들에서, 하나 또는 두 개 패킷들에 대한 상태 정보 (906a)를 삭제하는 것은 또한 송신될 더 많은 패킷들을 위하여 슬롯들을 비운다.

제 1 예 플로릿 (904a)을 마무리하기 위해, 제 3 패킷 (908c)은 발송 상태 (910c)를 가지며, 이는 이 패킷 (908c)에 대하여 어떠한 응답도 아직 수신되지 않는 것을 의미한다. 제 4 패킷 (908d)는 계류중인 상태(pending status) (910d)를 가지며, 이는 패킷이 플로릿 (904a)에 추가되었지만, 그러나 네트워크 (930)로 아직 발송되지 않은 것을 의미한다.

제 2 예 플로릿 (904b)에 대하여, 모든 네 개의 패킷들 (912a-d)이 네트워크 (930)로 발송되었다. 제 2 플로릿 (904b)에 대한 상태 정보 (906b)는 제 3 패킷 (912c)에 대하여 SACK 상태 (914c)를 나타낸다. SACK 상태 (914c)는 제 3 패킷 (912c)이 수신-측 (950) 전송 컨텍스트에 의해 수신되었다는 것을 나타낸다. SACK 상태 (914c)는 또한 제 1 패킷 (912a)이 또한 수신되었다는 것을 나타낼 수 있고, 이는 제 1 패킷 (912a)에 대한 ACK 상태 (914a) 상태를 암시한다. 한편, 제 2 (912b) 및 제 4 (912c) 패킷들은 이들 패킷들(912b), (912c)에 대하여 어떠한 응답들도 아직 수신되지 않았다는 것을 나타내는 발송 상태들 (914b), (914c)을 가진다.

송신-측 (950) 전송 컨텍스트가 순서가 바뀐 패킷들을 수신한 때 SACK 메시지들이 송신-측 (950) 전송 컨텍스트에 의해 사용될 수 있다. 제 2 예 플로릿 (904b)에 대하여, 제 1 패킷 (912a)이 수신되고, 그런 다음 제 3 패킷 (912c)이 수신된다. 이것은 제 2 (912b) 패킷은 발송 상태 (914b)를 가지지만, 제 2 패킷 (912b)은, 제 3 패킷 (912c) 전에 수신-측 (950)에 도달하지 않았다는 것을 암시한다. 사실은, 제 2 패킷 (912b)은 네트워크 (930)에 의해 드랍될 수 있다. 일부 구현예들에서, SACK 응답은 순서에 맞게 수신-측 (950)에서 수신된 마지막 패킷의 패킷 시퀀스 번호(여기서, 제 1 패킷 (912a)에 대한 시퀀스 번호) 및 순서에 맞지 않게 수신된 제 1 패킷에 대한 패킷 시퀀스 번호 (여기서, 제 3 패킷 (912c)에 대한 시퀀스 번호)를 포함하였을 수 있다. 따라서, 예를 들어, 숫자 패킷 시퀀스 번호들이 사용되었다고 가정하면, SACK 응답은 상기“1, 3”을 가질 수 있다. 이런 식으로, SACK 응답은 제 2 패킷 (912b)이 송신-측 (900) 전송 컨텍스트에 의해 재송신될 필요가 있다는 것을 효율적으로 표시할 수 있다.

응답 메시지들은 일반적으로 데이터 패킷들과 동일한 방식으로 네트워크 (930)를 횡단한다. 따라서, 응답 메시지들이 또한 네트워크 (930)에서 드랍될 수 있다. 이것은 때때로 수신-측 (950) 전송 컨텍스트가 하나의 특정 패킷이 도달되지 않은 것을 나타내는 하나 초과의 SACK를 생성할 수 있다는 것을 의미한다. 예를 들어, 제 2 예 플로릿 (904b)에 대하여, “1, 3”을 말한 SACK이 네트워크 (930)에 드랍될 수 있다. 4 패킷 (912d)이 성공적으로 수신-측 (950)에 도달하였다고 가정하면, 송신-측 (900) 전송 컨텍스트는 “1, 3-4”를 말하는 SACK를 생성할 수 있는데 왜냐하면 수신-측 (950) 전송 컨텍스트가 아직 제 2 (912b) 패킷을 수신하지 않았기 때문이다.

확장된 예제는 송신-측 (900) 전송 컨텍스트가 패킷들이 재송신될 필요가 있는지를 어떻게 결정할 수 있는지를 더 잘 예시한다. 송신 측 (900)에서 플로릿은 패킷 시퀀스 번호들 1, 2, 3, 4, 5, 6을 갖는 여섯 개의 패킷들을 발송하였다고 가정한다. 수신-측 (950)상에서 플로릿은 시퀀스 번호들 1, 3, 5, 및 6을 갖는 패킷들을 수신하였고 시퀀스 번호들 2 및 4를 갖는 패킷들은 네트워크 (930)에서 드랍되었다고 추가로 가정한다. 이 시나리오를 가정하여, 수신-측 (950)은 이하의 응답들을 생성할 수 있다:

패킷 번호 1 수신시: ACK(1)

패킷 번호 3 수신시: SACK(1, 3)

패킷 번호 5 수신시: SACK(1, 5)

패킷 번호 6 수신시: SACK(1, 5-6)

만약 이들 확인 응답 메시지들의 전부가 송신-측 (900) 전송 컨텍스트에 수신되면, 그러면 제 1 SACK은 패킷 번호 2의 재송신을 트리거할 수 있다. 제 2 SACK는 단지 패킷 번호 4의 재송신을 트리거할 수 있는데, 왜냐하면 송신-측 (900) 전송 컨텍스트는 패킷 번호 2를 이미 재송신하였다고 결정할 수 있기 때문이다. 제 3 SACK은 아마 임의의 재송신을 트리거하지 않을 것이다.

그러나 제1 SACK이 네트워크 (900)에서 손실된 것을 가정하여, 제 2 SACK (SACK(1, 5))의 수신은 패킷들 번호 2, 3, 및 4를 재송신하도록 송신-측 (900) 전송 컨텍스트를 트리거 할 수 있다. 패킷 번호 2가 패킷 번호 6 뒤에 도달한다고 가정하여, 수신-측 (950) 전송 컨텍스트는 패킷 번호 4가 아직 도달되지 않는 것을 송신-측 (900)에 알리기 위해 SACK (3, 5-6)을 생성할 것이다. 패킷 번호 3이 다음에 도달한다고 가정하여, 수신-측 (950) 전송은 이 패킷을 복제로서 인식할 수 있고, 추가 응답을 발송하지 않고서 복제 패킷을 폐기할 것이다.

일부 구현예들에서, 송신-측 (900) 전송 컨텍스트는 재송신할 것이고, 확인 응답되지 않은 임의의 패킷들을 계속해서 재송신할 것이다. 예를 들어, 제 3 플로릿 (904c)에 대하여, 제 4 패킷 (916d)은 발송 상태 (918d)를 가져서, 주기적으로 재송신될 수 있다. 플로릿이 하나 초과의 확인 응답되지 않은 패킷을 가질 때, 일반적으로 이들 확인 응답되지 않은 패킷들은 최저의 패킷 시퀀스 번호를 갖는 패킷으로부터 가장 높은 패킷 시퀀스 번호를 갖는 패킷까지 차례 차례로 재송신될 것이다. 예를 들어, 제 2 플로릿 (904b)에 대하여, 송신-측 (900) 전송 컨텍스트는 하나 또는 둘 모두 패킷들 (912b), (912c)이 확인 응답될 때까지 제 2 패킷 (912b), 그런 다음 제 4 패킷 (912d), 및 그런 다음 다시 제 2 패킷 (912b) 및 제 4 패킷 (912d)을 재송신 할 수 있다. 추가의 SACK 응답들이 도달한 때, 수신되지 않은 것으로 SACK 메시지에 의해 표시된 패킷들은 재송신할 패킷들의 리스트에 추가 또는 재-추가될 수 있다. 송신-측 (900) 전송 컨텍스트는 많은 경우들에서, 재송신 패킷들로 네트워크 (930)가 플러딩(flooding)되는 것을 피하도록 구성될 수 있다. 예를 들어, 송신-측 (900) 전송 컨텍스트는 최대 버스트 사이즈를 갖도록 구성될 수 있고, 이는 플로릿이 한번에 발송할 수 있는 패킷들의 최대 수를 나타낸다. 플로릿에 의해 발송된 패킷들의 수가 - 제 1 시간동안 발송된 패킷들 및 재송신되는 패킷들을 포함하여 - 버스트(bust) 사이즈에 도달한 때, 재송신될 필요가 있는 추가 패킷들은 지연될 수 있다.

일부 구현예들에서, 플로릿은 또한 적어도 가장 오래된 확인 응답되지 않은 패킷들이 확인 응답될 때 까지 새로운 패킷들을 송신하는 것을 중단할 수 있다. 예를 들어, 일부 구현예들에서, 플로릿은 제한된 수의 패킷들에 대한 상태 정보만을 유지할 수 있다. 예를 들어, 이들 구현예들에서, 플로릿은 여섯개의 패킷들까지에 대한 상태 정보를 유지할 수 있고 플로릿은 패킷들 번호 1 내지 6을 발송할 수 있다. 플로릿은 패킷 번호 1에 대하여가 아니라, 패킷들 번호 2, 3, 및 4에 대하여 응답들을 추가로 수신할 수 있다. 플로릿이 패킷 번호 1에 대한 확인 응답을 수신할 때까지, 플로릿은 패킷 번호 1에 대한 상태 정보를 유지하여서 이 패킷이 재송신될 수 있도록 할 필요가 있을 수 있다. 더욱이, 추가 패킷들에 대한 스페이스를 만들기 위해서 패킷 번호 1이 확인 응답되고 플로릿으로부터 제거될 때까지 플로릿은 임의의 새로운 패킷들을 추가할 수 없을 수 있다.

도 9a의 예제로 돌아가서, 제 3 예 플로릿 (904c)에 대하여, 모든 네 개의 패킷들 (916a-d)이 네트워크 (930)로 발송되었다. 제 3 플로릿 (904c)에 대한 상태 정보 (906c)는 제 1 패킷 (916a)이 차례 차례로 수신되었다는 것을 나타내는 제 1 패킷 (916a)에 대하여 ACK 상태 (918a)를 나나탠다.“차례 차례로 수신된(received in sequence)”는 해당 플로릿에 대하여 수신된 모든 패킷들은 제 1 패킷 (916a)의 패킷 시퀀스 번호를 바로 선행하는 순차적인 패킷 시퀀스 번호들을 갖거나 (예를 들어, 제 1 패킷 (916a)이 패킷 시퀀스 번호 “1”를 갖는다고 가정하고, 패킷 시퀀스 번호들이 최대 32를 갖는 카운터로부터 할당되고 순환될 수 있다(wrap around)고 가정하여, 선행하는 패킷 시퀀스 번호들은 “29, 30, 31, 0”을 가질 수 있다), 또는 제 1 패킷 (916a)이 “시퀀스의 시작(start of sequence)” 표시자를 가져서 이 플로릿 (904c)에 의해 발송된 제 1 패킷 이다는 것을 의미한다.

제 2 (916b) 및 제 3 (916c) 패킷들은, 그러나, NACK 상태들 (918b), (918c)를 가진다. NACK 상태들 (918b), (918c)은 제 2 (916b) 및 제 3 (916c) 패킷들이 수신 측 (950)에 도달하였지만, 그러나 하나의 이유 또는 다른 이유 때문에, 이들 패킷들 (916b), (916c)은 수신 측 (950)에서 수락되지 않았다는 것을 나타낸다. NACK 응답은 일반적으로 메시지를 수신한 패킷을 생성한 유저 애플리케이션 (902)으로 다시 전달된다. 유저 애플리케이션 (902)은 그런 다음 무엇을 해야하는지를 결정할 수 있다; 예를 들어, 유저 애플리케이션 (902)은 NACK 상태 (918b)을 갖는 패킷 (916b)은 재발송되어야 하고, 이 경우에 유저 애플리케이션 (902)는 플로우에 패킷 (916b)의 새로운 복사본을 놓을 수 있다고 결정할 수 있다. 유저 애플리케이션 (902)로 다시 NACK 응답을 전달하는 것외에, 그러나, 송신-측 (900) 전송 컨텍스트은 ACK 상태들에 유사하게 NACK 상태들 (918b), (918c)을 처리할 수 있고, 제 2 (916b) 및 제 3 (916c) 패킷들이 수행된 것으로 간주할 수 있다. 이것은 제 1 (916a), 제 2 (916b), 및 제 3 (916c) 패킷들 및 그것들의 대응하는 상태 정보 (918a-c)가 플로릿 (904c)로부터 제거될 수 있고, 추가 패킷들을 위해 새로운 슬롯들을 비어있게 한다는 것을 의미한다.

송신-측 (900) 전송 컨텍스트는 각각의 플로릿 (904a-c)에 대하여 다양한 타이머들을 유지할 수 있다. 예를 들어, 송신-측 (900) 전송 컨텍스트는 응답이 수신된 때 제 1 플로릿 (904a)에 대한 타이머를 시작할 수 있고, 다른 응답이 제 1 플로릿 (904a)에 대하여 수신된 때 매번 타이머를 리셋(reset)할 수 있다. 어떠한 응답들도 오랜 기간동안 수신되지 않은 때, 타이머는 만료(expire)될 수 있다. 이 때에, 송신-측 (900) 전송 컨텍스트는 일부 행동들을 취할 수 있다. 예를 들어, 만약 제 1 플로릿 (904a)에 큰 수의 아직 처리되지 않은 패킷들이 있다면, 송신-측 (900) 전송 컨텍스트는 상이한 경로로 플로릿 (904a)을 스위치할 것을 결정할 수 있다. 높은 수의 아직 처리되지 않은 패킷들은 플로릿 (904a)에 의해 사용되는 경로들이 매우 느리거나, 또는 어쩌면 고장난 경로들을 가진다는 것을 나타낼 수 있다. 송신-측 (900) 전송 컨텍스트는 또한 재송신을 위해 플로릿 (904a)내 임의의 아직 처리되지 않은 패킷들을 스케줄링할 수 있다.

도 9b는 응답들의 생성 및 패킷들의 수신의 수신-측 (950) 관리의 예를 예시한다. 도 9b의 예는 도 9a에 예시된 세개의 예제 플로릿(flowlet)들 (904a-c)의 수신을 예시한다. 도 9b에서, 각각의 세개의 예제 플로릿들에 대하여, 수신-측 (950) 전송 컨텍스트는 각각의 수신된 패킷에 대하여 각-플로릿 베이시스에 대한 상태 정보 (954a-c)를 유지한다. 상태 정보 (954a-c)를 이용하여, 수신-측 (950) 전송 컨텍스트는 예상되는 패킷들이 수신되지 않은 때를 결정할 수 있다. 수신-측 (950) 전송 컨텍스트는 그런 다음 송신-측 (900)이 누락 패킷들을 재송신할 것을 요청할 수 있다.

제 1 예 플로릿에 대하여, 상태 정보 (954a)는 제 1 패킷 (958a) 및 제 2 패킷 (958b)가 도달하였다는 것을 표시할 수 있다. 이 예에서, 수신-측 (950) 전송 컨텍스트가 제 1 패킷 (954a)의 성공한 수신을 확인 응답하는 ACK 응답을 생성할 수 있기 전에 제 2 패킷 (958b)이 도달하였다. 일반적으로, 수신-측 (950) 전송 컨텍스트는 아마 수신된 각각의 패킷에 대한 응답들을 자동으로 생성할 수 없고 큐잉(queue)할 수 없다. 대신에, 수신-측 (950) 전송 컨텍스트는 플로릿에서 패킷 수신시, 응답 생성이 필요한 것으로 플로릿에 마크(mark)할 수 있다. 수신-측 (950) 전송 컨텍스트는 플로릿이 응답을 생성할 필요가 있는지를 조사하기 위해 각각의 플로릿을 주기적으로 폴링(poll)할 수 있고, 그런 다음 응답을 생성하고 발송할 수 있다.

제 1 플로릿에 대하여, 이것은 제 2 패킷 (958b)이 도달된 후에만 제 1 플로릿이 응답을 생성할 것이다는 것을 의미한다. 이 지점에서, 수신-측 (950) 전송 컨텍스트는 플로릿의 상태 정보 (954a)를 조사할 수 있고, 제 1 (958a) 및 제 2 (958b) 패킷들이 도달하였다는 것을 나타내는 누적 응답(cumulative response)을 생성하기 위해 이 정보를 사용할 수 있다. 응답은 또한 이들 패킷들이 그것들의 순차적인 순서로 도달하였다는 것을 표시할 수 있고 이는 지금까지 어떠한 패킷들도 도달하는데 실패하지 않았다는 것을 의미한다. 패킷들 (958a), (958b)이 차례 차례로 도달하기 때문에, 확인 응답은 ACK (960)일 것이고, ACK (960)은 가장 최근에 수신된 패킷 (즉, 제 2 패킷 (958b))의 패킷 시퀀스 번호를 포함할 것이다.

다른 상황들에서, 제 1 플로릿은 각각의 제 1 (958a) 및 제 2 (958b) 패킷들에 대한 ACK를 생성할 수 있다. 예를 들어, 제 1 예 플로릿은 제 1 패킷 (958a)이 도달한 후에 그리고 제 2 패킷 (958b)이 도달한 후에 응답들을 생성하도록 스케줄링될 수 있다. 둘 모두의 경우들에서, 응답들은 ACK들일 것이고, 각각은 선행하는 패킷의 패킷 시퀀스 번호를 가진다.

ACK (960)을 생성하여 송신한 후에, 제 1 플로릿 은 적어도 제 1 패킷 (958a)에 대한 상태 정보를 제거할 수 있다. 플로릿은 트랙 가장 최근에 수신된 시퀀스 번호를 추적하기 위해 제 2 패킷 (958b)의 패킷 시퀀스 번호를 유지할 수 있다. 플로릿은, 그러나, 패킷들 그자체들이 수신 유저 애플리케이션 (952)로 송신되게 할 수 있다. 일반적으로, 수신-측 (950) 전송 컨텍스트는 패킷들 버퍼링(buffering)을 피할 수 있고, 가능한 한 빨리그것들의 의도된 유저 애플리케이션 (952)으로 그것들을 발송할 수 있다.

제 2 예 플로릿에 대하여, 상태 정보 (954b)는 두개의 패킷들이, 이 경우에서 제 1 패킷 (962a) 및 제 3 패킷 (962c)이 도달하였고, 시간 제 3 패킷 (962c)이 수신된 시간에 제 2 패킷 (962b)이 누락된 것을 나타낸다. 여기서, 플로릿은 제 1 패킷 (962a)이 수신된 후에 ACK를 생성할 수 있지만, 그러나 제 3 패킷 (962c)후에, 플로릿은 SACK (964)를 생성할 것인데 이는 제 2 패킷 (962b)이 이 지점에서, 누락되었기 때문이다. SACK(964)는 제 2 패킷이 수신되지 않았다는 것을 송신-측 (900) 전송 컨텍스트에 통지할 수 있다. 예를 들어, SACK 응답은 SACK (960) 메시지에 제 1 패킷 (962a) 및 제 3 패킷 (962c)의 패킷 시퀀스 번호들을 포함할 수 있다. SACK 응답들은 또한 누적될 수 있다. 예를 들어, 이 예에서 SACK (964)가 발송되기 전에 제 4 패킷이 도달하면, 그러면 플로릿은 제 1 (962a), 제 3 (962c), 및 제 4 패킷들의 수신을 나타내는 SACK를 생성할 수 있다.

예제를 계속보면, 제 2 플로릿이 제 1 (962a) 및 제 3 (962c) 패킷들에 대한 SACK (964)을 송신한 후에, 누락(missing) 제 2 패킷 (962b)이 도달할 수 있다. 예를 들어, 네트워크 (930)에 느림 때문에 제 2 패킷 (962b)이 지금 막 도달 하였다. 제 2 패킷 (962b)은 또한 그것이 재송신되었다는 것을 의미하는 SACK (964)에 응답하여 도달될 수 있다. 이 예에서, 제 2 패킷 (962b)은 제 2 시간에 도달한다. 예를 들어, SACK (964)이 네트워크 (964)에서 드랍될 수 있기 때문에 제 2 패킷 (962b)의 제 2 복사본이 도달할 수 있다. 추가적으로, 송신-측 (900) 플로릿에서 타이머가 만료될 수 있고, 모든 확인응답되지 않은 패킷들이 재송신될 수 있다. 상태 정보 (954b)가 수신-측 (950) 전송 컨텍스트가 제 2 패킷 (962b)의 제 2 복사본이 복제되었다는 것을 인식하는 것을 허용한다. 플로릿은 이어서 복제된 복사본을 드랍할 수 있다.

제 3 예 플로릿에 대하여, 상태 정보 (954c)는 세개의 패킷들 (966a-c)이 도달하였다는 것을 나타낸다. 플로릿은 제 1 패킷 (966a)을 수락하고, 송신-측 (900) 전송 컨텍스트에 알리기 위해 ACK (968a)을 생성한다. 플로릿은, 그러나, 제 2 (966b) 및 제 3 (966c) 패킷들을 수락하지 않을 수 있다. 이것은 예를 들어, 수신 유저 애플리케이션 (952)이 메모리내 버퍼들을 다 써버리고, 임의의 더 많은 패킷들을 수락할 수 없을 때 발생할 수 있다. 이것이 발생한 때, 플로릿은 수락되지 않는 패킷들 (966b), (966c)에 대한 NAK (968b), (968c) 메시지들을 생성할 수 있다.

일부 구현예들에서, 수신-측 (950) 전송 컨텍스트는 응답 메시지들을 생성하는 것을 중단할 수 있다. 이것은 새로운 패킷들이 송신-측 (900)에서 거의 빈 플로릿에 추가되지 않고 해당 플로릿로부터 패킷들이 네트워크에서 드랍되었을 때 발생할 수 있다. 이 경우에 패킷들이 누락된 것을 나타내는 SACK일 것인 응답을 생성하기 위해 수신-측 (950) 전송 컨텍스트에 대하여, 수신-측 (950) 플로릿은 다른 패킷을 수신할 것인데 이는 송신-측 (900) 플로릿이 새로운 패킷들을 수신하지 않기 때문에, 발생하지 않을 수 있다. 일부 구현예, 이 상황을 방지하기 위한 하나의 방법은 예를 들어, 적고 빠르게 운용하는 플로릿들에 빈번하게 패킷들을 할당함으로써 플로릿이 거의 비어있게 되는 것을 허용하지 않는 것을 보장하는 것이다. 일부 구현예들에서, 아직 처리되지 않은 패킷들로 스턱(stuck)되는 플로릿을 방지하는 다른 방법은 동적으로 다수의 플로릿들을 조절하는 것이다. 일부 구현예들에서, 다른 해결책은 긴시간 동안 아직 처리되지 않은 패킷들을 갖는 플로릿들을 타임 아웃하여, 해당 플로릿들을 다른 경로로 이동시키고, 해당 플로릿들에 아직 처리되지 않은 임의의 패킷들을 재발송하는 것이다.

도면들 9a 및 9b의 예들에 도시된 바와 같이, 완화된 신뢰할 수 있는 데이터그램 전송 서비스는 응답들 및 모든 패킷들이 결국에는 전달되는 것을 보장하기 위해 어쩌면 상실된 패킷들의 재송신을 사용할 수 있다. 이런 식으로, 완화된 신뢰할 수 있는 데이터그램 전송은 무시가능한 패킷 드랍 비율보다 더 많이 갖는 네트워크들 (930)에 대하여 사용될 수 있다. 이들 예들에 예시된 바와 같이, 패킷들은 그것들의 패킷 시퀀스 번호들에 대하여 뿐만 아니라, 패킷들이 서로 관련있는 순서에 대하여 순서가 바뀌어서 수신-측 (950)에 도달할 수 있다.

도면들 10a-10b는 플로릿들 (1002a-c)로 분할된 단리 패킷 플로우, 패킷들 (1004a-d), (1006a-d), (1008a-d)이 수신 유저 애플리케이션에 의해 수신되는 순서의 예를 예시한다. 이 간략화된 예제에서, 예시된 패킷들 (1004a-d), (1006a-d), (1008a-d)이 하나의 발송 유저 애플리케이션에 의해 발송되었고 하나의 수신 유저 애플리케이션에 의해 수신된다. 예시된 패킷들 (1004a-d), (1006a-d), (1008a-d)는 발송 유저 애플리케이션에 의해 송신될 때, 이 예제 대하여, 패킷들 (1004a-d), (1006a-d), (1008a-d)은 특정 시퀀스를 가진다. 예를 들어, 패킷들 (1004a-d), (1006a-d), (1008a-d)은 비디오 스트림의 일부일 수 있고, 비디오 스트림의 순차적인 프레임들을 전송할 수 있다. 패킷들 (1004a-d), (1006a-d), (1008a-d)는 패킷들의 올바른 순서를 수신 애플리케이션에 알리기 위해서 발송 유저 애플리케이션에 의해 시퀀스 식별자를 할당받을 수 있다.

상기에서 논의된 바와 같이, 패킷들 (1004a-d), (1006a-d), (1008a-d)는 그것들이 원래 발송된 순서에 맞지 않게 수신 유저 애플리케이션에 도달할 수 있다. 이것은 다른 이유들 중에서 네트워크에서 드랍들, 플로릿들에 대한 경로들이 바뀌거나, 및/또는 플로릿들이 재시작되었기 때문일 수 있다. 순서가 바뀌어서 도달하는 패킷들 (1004a-d), (1006a-d), (1008a-d)는 패킷들의 각각의 그룹에 의해 취해진 네트워크상에 경로들에서의 차이들에 의해 또한 야기될 수 있다. 패킷들 (1004a-d), (1006a-d), (1008a-d)는 따라서 목적지 시스템에 도달한 때 재순서화되는 것을 필요로 할 수 있다. 도 10a는 시간에 대한 패킷들 (1004a-d), (1006a-d), (1008a-d)의 도달을 예시하고 패킷들 (1004a-d), (1006a-d), (1008a-d)이 어떻게 메모리에 저장될 수 있는지를 예시한다. 도 10b는 패킷들 (1004a-d), (1006a-d), (1008a-d)을 그것들의 의도된 시퀀스로 배치하기 위해 그것들의 재순서화를 예시한다.

도 10a의 예제에서, 패킷 플로우는 세개의 플로릿들 (1002a-c)로 분할되었고, 네 개의 패킷들이 각각의 플로릿 (1002a-c)을 이용하여 수신되었다. 도 10a의 예는 시간에 대한 각각의 패킷들 (1004a-d), (1006a-d), (1008a-d)의 도달을 예시한다. 도 10a는 패킷들을 수신하기 위해 메모리에 구성된 버퍼들 (1010)의 예를 또한 예시한다. 일부 구현예들에서, 버퍼들 (1010)은 수신 유저 애플리케이션에 의해 미리 구성된다. 이들 구현예들에서, 버퍼 (1010)는 호스트 디바이스의 메모리에 구성될 수 있다.

상기에서 논의된 바와 같이, 각각의 플로릿 (1002a-c)에 패킷들 (1004a-d), (1006a-d), (1008a-d)은 그것들의 개별 플로릿들 (1002a-c)내에 그것들의 순서를 수립할 수 있는 패킷 시퀀스 번호를 할당 받을 수 있다. 이 예에서, 패킷 시퀀스 번호들은 문자들 a, b, c, 및 d에 의해 표시된다. 제 1 플로릿 (1002a)에 대하여, 제 2 패킷 (1004b)이 먼저 도달하였고, 이어 제 1 패킷 (1004a), 제 4 패킷 (1004d), 및 제 3 패킷 (1004c)가 도달하였다. 앞에서 언급된 바와 같이, 패킷들 (1004a-d)이 도달한 순서는 패킷 드랍들, 패킷 재송신들, 및 불완전한 네트워크에서 발생할 수 있는 다른 이슈들에 기인할 수 있다. 제 2 플로릿 (1002b)에 대하여, 제 1 패킷 (1006a)이 먼저 도달하고, 그런 다음 제 4 패킷 (1006d), 제 2 패킷 (1006b), 및 그런 다음 제 3 패킷 (1006c), 해당 순서로 도달한다. 제 3 플로릿 (1002c)에 대하여, 제 1 패킷 (1008a)이 먼저 도달하였고, 그런 다음 좀 나중에, 제 2 패킷 (1008b), 제 4 패킷 (1008d), 및 제 3 패킷 (1008c)가 도달하였다.

이 예제를 설명하는 목적을 위하여, 패킷들 (1004a-d), (1006a-d), (1008a-d)는 그것들이 목적지 시스템에서 수신된 순서로 버퍼들 (1010)에 배치된다. 또한 이 예제의 설명의 목적을 위하여, 버퍼들 (1010)은 왼쪽에서 오른쪽으로 채워진다. 버퍼들 (1010)은 다른 식으로, 임의의 편리한 순서로 채워질 수 있다는 것이 이해되어야 한다. 이 예에서, 버퍼들 (1010)의 일부는 사용중이고(1012), 또는 그렇지 않으면, 흔히 해당 경우일 때 이용 가능하지 않다.

플로릿 (1002a-c)내 패킷들 (1004a-d), (1006a-d), (1008a-d)는 플로릿, (1002a-c)내 다른 패킷들 (1004a-d), (1006a-d), (1008a-d)에 대하여 도달 수선을 가지지만, 패킷들 (1004a-d), (1006a-d), (1008a-d)은 또한 플로릿들 (1002a-c)에 걸쳐 도달 순서를 가진다. 이 예에서, 제 1 플로릿 (1002a)가 전달 패킷 (1004b)을 전달하기 위해 처음이고, 바로 뒤이어 제 3 플로릿 (1008a)이다. 이들 두개의 패킷들 (1004b), (1008a)은 해당 순서로 버퍼들 (1010)에 기록될 수 있다. 일부 경우들에서, 이들 제 1 두개의 패킷들 (1004b), (1008a)은 대략 동일한 시간 (예를 들어, 동일한 클럭 사이클에)에 플로릿들 (1002a-c)에 의해 전달될 수 있다. 이런 경우에, 패킷들 (1004b), (1008a)이 저장되는 순서는 그것들의 플로릿 (1002a), (1002c) 아이덴티티에 기반될 수 있고, 또는 저장 순서는 임의일 수 있다.

예를 계속 보면, 패킷 (1008a) 다음에 제 2 플로릿 (1002b)로부터 두개의 패킷들 (1006a), (1006d)가 뒤따를 수 있고, 뒤이어 제 1 플로릿 (1002a)로부터의 패킷 (1004a)가 뒤따른다. 제 3 플로릿 (1002c)은 다음 패킷 (1008b)을 제공할 수 있고, 이어 제 1 (1002a), 제 2 (1002b), 및 제 3 (1002c) 플로릿들로부터, 개별적으로 패킷들 (1004d), (1006b), (1008d)이 뒤따른다. 이 예에서 마지막 세개의 패킷들 (1006c), (1004c), (1008c)은 개별적으로 제 2 (1002b), 제 1 (1002a), 및 제 3 (1002c) 플로릿들에 의해 전달된다.

일단 버퍼들 (1010)에 저장된 후에, 패킷들 (1004a-d), (1006a-d), (1008a-d)는 그것들의 플로릿들 (1002a-c)에 대하여 뿐만 아니라 서로에 대하여 순서가 바뀐다. 도 10b는 그것들의 의도된 시퀀스로 레코딩되고 놓여진 패킷들 (1004a-d), (1006a-d), (1008a-d)을 예시한다. 상기에서 언급한 바와 같이, 발송 유저 애플리케이션은 시퀀스 식별자를 각각의 패킷에 할당할 수 있다. 이 예에서, 제 1 플로릿 (1002a)을 통하여 송신된 패킷들 (1004a-d)의 그룹이 첫번째이고 차례 차례로, 이어 제 2 플로릿 (1002b)로부터의 패킷들 (1006a-d)의 그룹 및 제 3 플로릿 (1002c)로부터의 패킷들 (1008a-d)의 그룹이 뒤따른다.

패킷 재순서화는 드라이버 프로그램에 의해 및/또는 수신 유저 애플리케이션에 의해 실행될 수 있다. 드라이버 프로그램이 패킷 재순서화를 관리하는 구현예들에서, 드라이버 프로그램은 수신 유저 애플리케이션이 그것들을 액세스하기 전에 패킷들 (1004a-d), (1006a-d), (1008a-d)을 재순서화할 수 있다. 추가 메모리(1020)가 패킷들 (1004a-d), (1006a-d), (1008a-d)을 재순서화하기 위해 이용가능할 수 있고, 패킷들 (1004a-d), (1006a-d), (1008a-d)은 그것들의 적절한 순서로 이 추가 메모리(1020)에 복사될 수 있다. 대안적으로 또는 추가적으로, 패킷들 (1004a-d), (1006a-d), (1008a-d)은 버퍼들(1010) 사이에서 그것들을 복사함으로써 재순서화될 수 있다.

III. 방법들

도면들 11-14은 커널 바이패스 프레임워크 및, 일부 구현예들에서, 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 이용하여 네트워크 상에서 패킷들을 송신하기 위한 프로세스들의 예들을 예시한다. 이들 프로세스들은 상기에서 설명된 시스템들, 예컨대 예를 들어 도면들 4, 5a-5b, 6a-6b, 및 7a-7b에 대하여 설명된 시스템들에 의해 구현될 수 있다. 각각의 예 프로세스에 대한 단계들은 이해의 용이를 위해 예시되고, 개별 단계들은 주어진 외에 순서로 실행될 수 있고, 추가 단계들을 포함할 수 있고, 및/또는 더 적은 단계들로 결합될 수 있다.

도 11은 네트워크에 걸쳐 메시지들을 송신하려고 하는 유저 애플리케이션에 대해 전송 컨텍스트(transport context)가 결정될 수 있는 프로세스(1100)의 예를 예시한다. 예제 프로세스 (1100)는 커널 바이패스 프레임워크를 구현하도록 구성된 네트워크 어댑터 디바이스에 의해 실행될 수 있다. 네트워크 어댑터 디바이스는 호스트 디바이스와 통신할 수 있고, 호스트 디바이스는 네트워크를 통하여 메시지들을 발송하려고 하는 유저 애플리케이션상에서 운용될 수 있다.

단계 (1102)에서, 네트워크 어댑터 디바이스는 메시지 및 메시지와 관련된 목적지 정보를 수신할 수 있다. 메시지 및 목적지 정보는 호스트 디바이스로부터 수신될 수 있다. 메시지는 대부분의 경우들에서, 호스트 디바이스상에서 실행하는 유저 애플리케이션에 의해 생성될 수 있다. 목적지 정보는 일반적으로 네트워크에서 메시지가 발송될 곳을 설명한다. 대부분의 경우들에서, 목적지 정보는 발송 유저 애플리케이션에 의해 제공된다.

단계 (1104)에서, 네트워크 어댑터 디바이스는 목적지 정보를 조사할 수 있다. 목적지 정보는 상이한 방법들로 메시지의 의도된 수신자를 설명할 수 있다. 예제를 위해, 목적지 정보는 네트워크 어드레스 (1106), 예컨대 네트워크상에 시스템의 IP 어드레스 또는 Mac 어드레스, 및/또는 네트워크상의 시스템상에서 운용하는 가상 기계의 IP 어드레스일 수 있다. 대안적으로 또는 추가적으로, 목적지 정보는 패킷 플로우에 대한 플로우 식별자 (1108)일 수 있다. 플로우 식별자 (1108)는 수치 값일 수 있고, 및/또는 대한 소스 어드레스 및 목적지 어드레스의 조합일 수 있다. 대안적으로 또는 추가적으로, 목적지 정보는 어드레스 핸들(address handle)(1110)일 수 있다. 어드레스 핸들 (1110)은 패킷들을 생성하기 필요로 될 수 있는 전송 컨텍스트 및/또는 정보를 참조하는 소프트웨어 변수(variable) 또는 포인터일 수 있다. 예를 들어, 어드레스 핸들 (1110)은 네트워크 어드레스 맵 객체에 대한 참조내용(reference)일 수 있다. 어드레스 맵 객체는 적절한 전송 컨텍스트에 대한 참조 내용을 저장할 수 있고, 패킷들, 예컨대 미리-생성된 패킷 헤더들을 송신하기 위한 정보를 또한 저장할 수 있다. 단계 (1112)에서, 네트워크 어댑터 디바이스는 어드레스 핸들 (1110)을 이용하여, 네트워크 어드레스 맵 객체를 결정할 수 있다.

단계 (1114)에서, 네트워크 어댑터 디바이스는 목적지 정보를 이용하여 전송 컨텍스트(transport context)를 결정할 수 있다. 대부분의 구현예들에서, 결정된 전송 컨텍스트 네트워크상에 특정 목적지와 연관되고, 여기서 목적지는 네트워크상에 시스템, 및/또는 네트워크상에 시스템에서 운용하는 가상 기계, 및/또는 네트워크상의 시스템에서 운용하는 유저 애플리케이션, (어쩌면 가상 기계에서 운용하는) 이다. 전송 컨텍스트는 메시지가 그것의 의도된 목적지에 도달하는 것을 보장하는 것을 포함하여 네트워크를 통한 메시지의 송신을 관리할 수 있다. 일부 구현예들에서, 전송 컨텍스트는 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 이용하여 구현된다.

몇몇의 옵션 단계들이 프로세스 (1100)의 예를 위하여 또한 예시된다. 제 1 옵션 단계 (1116)에서, 네트워크 어댑터 디바이스는 메시지 및 결정된 전송 컨텍스트를 이용하여 패킷을 생성할 수 있다. 패킷을 생성하는 것은 패킷 헤더를 생성하는 것 및 메시지 바디를 패킷 페이로드에 배치하는 것을 포함할 수 있다. 일부 구현예들에서, 미리-생성된 헤더가 결정된 전송 컨텍스트와 연관될 수 있다. 미리-생성된 패킷 헤더는 네트워크를 통하여 패킷을 라우팅하기 위한 정보, 예컨대 소스 및 목적지 어드레스들 및/또는 포트들을 포함할 수 있다. 전송 컨텍스트는 일반적으로 특정 목적지와 관련되기 때문에, 라우팅 정보는 미리 알려지고, 패킷 헤더는 네트워크 어댑터 디바이스에 미리 생성되고 저장될 수 있다.

제 2 옵션 단계 (1118)에서, 네트워크 어댑터 디바이스는 결정된 전송 컨텍스트를 이용하여, 단계 (1116)에서 생성된 패킷을 송신할 수 있다.

도 12는 어드레스 핸들을 획득하기 위한 프로세스(1200)의 예를 예시한다. 예제 프로세스 (1200)는 네트워크 어댑터 디바이스에 의해 실행될 수 있다. 네트워크 어댑터 디바이스는 호스트 디바이스와 통신할 수 있고, 호스트 디바이스는 네트워크를 통하여 메시지들을 발송하려고 하는 유저 애플리케이션상에서 실행될 수 있다.

단계 (1202)에서, 네트워크 어댑터 디바이스는 새로운 어드레스 핸들을 위한 요청을 수신할 수 있다. 요청은 유저 애플리케이션에 의해 생성될 수 있고, 네트워크상에서 목적지를 설명하는 정보를 포함할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 예를 들어, 네트워크 어댑터 디바이스상에 메모리에 저장될 수 있는 어드레스 맵에 대한 액세스를 가질 수 있다. 어드레스 맵은 호스트 디바이스상에서 운용하는 유저 애플리케이션들이 통신하려고 하는 네트워크상의 시스테들에 대한 어드레스 정보를 저장할 수 있다. 네트워크 어댑터 디바이스는 단계 (1204)에서, 단계 (1202)에서 수신된 요청이 새로운 목적지에 대한 것인지 여부를 결정하기 위해 어드레스 맵을 이용할 수 있다. 요청은 요청에 제공된 어드레스 정보가 네트워크 어댑터 디바이스에 알려지지 않은 때 새로운 목적지에 대한 것이다. 예를 들어, 네트워크 어댑터 디바이스는 알려진 목적지들을 저장하는 어드레스 맵에서 목적지 정보를 찾지 못할 수 있다.

새로운 어드레스 핸들에 대한 요청이 새로운 목적이 대한 것이 아니면, 그러면, 단계 (1206)에서, 네트워크 어댑터 디바이스는 목적지 정보를 이용하여 전송 컨텍스트를 결정할 수 있다. 결정된 전송 컨텍스트는 전송 컨텍스트와 관련된 목적지에 대한 어드레스 핸들을 위한 앞선 요청에 의해 구성될 수 있다. 네트워크 어댑터 디바이스는 예를 들어, 목적지 정보를 이용하여 어드레스 맵을 인덱싱(index)하고, 어드레스 맵으로부터 올바른 전송 컨텍스트에 대한 참조내용 (또는 전송 컨텍스트를 설명하는 데이터 구조)를 추출함으로써 전송 컨텍스트를 결정할 수 있다.

새로운 어드레스 핸들에 대한 요청이 새로운 목적지에 대한 것이면, 그러면 네트워크 어댑터 디바이스는 단계 (1210)에서 목적지 정보에 의해 설명된 목적지에 대한 새로운 전송 컨텍스트를 생성할 수 있다. 단계 (1212)에서, 네트워크 어댑터 디바이스는 새로운 전송 컨텍스트에 새로운 연결에 대한 상태 정보를 저장할 수 있다. 이 단계는 단계 (1208)에서 수립된 연결과 전송 컨텍스트를 연관시키는 단계를 포함할 수 있다. 전송 컨텍스트는 그 후에 예를 들어, 네트워크에 걸친 경로들의 설정 및 해지, 패킷들 송신, 및/또는 아직 처리되지 않은 패킷들에 대한 상태 정보 유지를 포함하여 연결을 관리할 수 있다.

단계 (1216)에서, 네트워크 어댑터 디바이스는 새로운 어드레스 맵 객체를 생성할 수 있다. 새로운 어드레스 맵 객체를 생성하는 단계는 네트워크상의 목적지로 패킷들을 라우팅하기 위한 소스 및 목적지 정보를 포함하는 미리-구성된 패킷 헤더를 생성하고 저장하는 단계를 포함할 수 있다. 새로운 어드레스 맵 객체는 또한 단계 (1210)에서 생성된 새로운 전송 컨텍스트, 또는 단계 (1206)에서 결정된 전송 컨텍스트와 관련될 수 있다.

단계 (1208)에서, 네트워크 어댑터 디바이스는 목적지 정보와 관련된 네트워크 상의 시스템과 새로운 연결을 수립할 수 있다. 새로운 연결을 수립하는 단계는 확인 단계들, 예컨대 요청 유저 애플리케이션이 목적지 시스템와 통신하는 것이 허용된 지를 체크하는 단계를 포함할 수 있다. 연결을 수립하는 단계는 네트워크 어댑터 디바이스와 목적지 시스템 간에 메시지들의 교환을 또한 포함할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 이하에서 설명되는 단계들 (1218) 및 (1220) 후에 새로운 연결을 수립할 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 단계들 (1218) 및 (1220) 후에 연결을 수립할 수 있고, 다른 동작들을 실행한다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 메시지가 단계 (1220)에서 리턴된 어드레스 핸들과 관련된 목적지 시스템에 먼저 송신된 때 연결을 수립할 수 있다.

단계 (1218)에서, 네트워크 어댑터 디바이스는 새로운 어드레스 핸들을 생성할 수 있다. 어드레스 핸들은 새로운 어드레스 맵 객체를 지칭할 수 있고, 예를 들어, 어드레스 핸들은 네트워크 어댑터 디바이스의 메모리내 어드레스에 대한 소프트웨어 포인터(software pointer)일 수 있다.

단계 (1220)에서, 새로운 어드레스 핸들은 요청 유저 애플리케이션에 리턴될 수 있다. 요청 유저 애플리케이션은 나중 사용을 위해 새로운 어드레스 핸들을 저장할 수 있다.

도 13은 각각의 패킷이 전달되는 것을 보장하기 위해 각각의 패킷에 대한 상태를 모니터링하고 네트워크를 통하여 패킷들을 송신하기 위한 프로세스(1300)의 예를 예시한다. 예제 프로세스 (1300)는 커널 바이패스 프레임워크를 구현하도록 구성된 네트워크 어댑터 디바이스에 의해 실행될 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 이용하여 패킷들을 전송하고 그것들의 상태를 모니터링할 수 있다.

단계 (1302)에서, 네트워크 어댑터 디바이스는 메시지들 및 목적지 정보를 수신할 수 있다. 메시지들 및 목적지 정보는 호스트 디바이스로부터 수신될 수 있고 복수의 발송 큐들로부터 하나의 발송 큐에서 수신될 수 있다. 목적지 정보는 메시지를 수신할 네트워크상에 목적지를 설명할 수 있다. 네트워크 어댑터 디바이스는 큐 쌍 중 발송 큐에서 메시지를 수신할 수 있다. 큐 쌍(queue pair)은 호스트 디바이스 상에서 실행하는 유저 애플리케이션과 연관될 수 있다.

단계 (1304)에서, 네트워크 어댑터 디바이스는 목적지 정보 및 발송 큐의 아이덴티티를 이용하여 전송 컨텍스트 결정할 수 있다. 대부분의 구현예들에서, 전송 컨텍스트는 특정 목적지와 연관될 수 있고, 여기서 목적지는 이 예에서, 목적지 정보 및/또는 발송 큐의 아이덴티티에 의해 식별된다. 발송 큐의 아이덴티티는 다수의 큐 쌍들 중에서 발송 큐를 식별하기 위해 네트워크 어댑터 디바이스에 의해 사용되는 문자와 숫자(alphanumeric) 값일 수 있다.

단계 (1305)에서, 네트워크 어댑터 디바이스는 각각의 메시지에 대하여 몇몇의 단계들을 실행할 수 있다. 제 1 옵션 단계 (1306)에서, 네트워크 어댑터 디바이스는 메시지 및 결정된 전송 컨텍스트를 이용하여 패킷을 생성할 수 있다. 전송 컨텍스트는 네트워크를 통하여 의도된 목적지로 패킷들을 라우팅하기 위해 필요한 정보, 예컨대 포트 번호, 네트워크 어드레스들, 및/또는 미리-생성된 패킷 헤더들을 제공할 수 있다. 네트워크 어댑터 디바이스는 하나의 패킷을 생성할 수 있고, 패킷의 페이로드로 메시지를 배치할 수 있다. 대안적으로 또는 추가적으로, 네트워크 어댑터 디바이스는 두개 이상의 패킷들을 생성할 수 있고, 여기서 각각의 패킷은 패킷들의 페이로드에 메시지의 일부를 포함한다. 일부 구현예들에서, 전송 컨텍스트는 또한 각각의 패킷에 패킷 시퀀스 번호를 할당할 수 있고, 여기서 패킷 시퀀스 번호는 패킷들이 발송되는 순서를 나타낸다.

단계 (1308)에서, 네트워크 어댑터 디바이스는 전송 컨텍스트를 이용하여 네트워크를 통하여 각각의 패킷을 송신할 수 있다. 전송 컨텍스트는 각각의 패킷의 송신을 관리할 수 있다. 단계 (1310)에서, 네트워크 어댑터 디바이스는 추가로 각각의 송신된 패킷에 대하여 상태를 모니터링할 수 있다. 전송 컨텍스트는 패킷 상태 모니터링을 또한 관리할 수 있다. 각각의 패킷의 상태는 패킷이 목적지 시스템에서 수신되었는지 여부를 표시한다. 일부 구현예들에서, 전송 컨텍스트는 네트워크상의 목적지로부터 응답 메시지들을 기대할 수 있고, 여기서 응답 메시지들은 하나 이상의 패킷들이 수신되었다는 것을 나타낸다.

적어도 세개의 유형들의 응답 메시지들이 수신될 수 있다. 첫번째, 단계 (1312)에서, 네트워크 어댑터 디바이스는 하나 이상의 패킷들이 목적지에서 수신되었다는 것을 나타내는 응답 메시지를 수신할 수 있다. 일부 구현예들에서, 이 응답은 하나 이상의 패킷들이 순서에 맞게(in order) 수신되었다는 것을 표시하고, 여기서 그것들의 순서는 그것들의 패킷 시퀀스 번호들에 의해 제공되고, 여기서 어떠한 패킷들도 시퀀스로부터 누락되지 않는다. 예를 들어, 응답은 패킷들 번호 1, 2, 및 3이 수신되었다는 것을 나타내는 “3”을 말할 수 있다.

두번째, 단계 (1314)에서, 네트워크 어댑터 디바이스는 하나 이상의 패킷들이 수신되지 않았다는 것을 나타내는 응답을 수신할 수 있다. 일부 구현예들에서, 이 응답 메시지는 도달한 패킷들의 패킷 시퀀스 번호들을 제공할 수 있고, 시퀀스 번호들에서의 갭에 의해 도달하지 않은 패킷들을 표시할 수 있다. 예를 들어, 응답에서 패킷 시퀀스 번호들 “1, 3”은 시퀀스 번호 “2”를 가진 패킷이 아직 도달하지 않았다는 것을 표시할 수 있다. 대안적으로, 일부 구현예들에서, 응답은 수신되지 않은 패킷들의 패킷 시퀀스 번호들을 열거할 수 있다. 예를 들어, 응답에서 패킷 시퀀스 번호들 “2-4”은 패킷들 2, 3 및 4가 아직 도달하지 않았다는 것을 표시할 수 있다.

세번째, 단계 (1316)에서, 네트워크 어댑터 디바이스는 패킷 재송신 요청을 포함하는 응답을 수신할 수 있다. 일부 구현예들에서, 이 응답은 패킷이 목적지에서 수신되었지만, 그러나 하나의 이유 또는 다른 이유 때문에, 패킷이 수락되지 않았다는 것을 나타낸다. 단계 (1318)에서, 네트워크 어댑터 디바이스는 이 응답을 호스트 디바이스로 전달할 수 있다. 호스트 디바이스는 왜 패킷이 재송신되어야 할 필요가 있는지를 결정할 수 있고, 및/또는 패킷을 재송신하기 위해 새로운 메시지를 생성할 수 있다.

네트워크 어댑터 디바이스는 어떠한 응답 메시지들도 수신되지 않거나, 또는 어떠한 응답 메시지들도 오랫동안 수신되지 않은 상황을 위해 또한 구성될 수 있다. 예를 들어, 네트워크 어댑터 디바이스는 패킷이 단계 (1310)에서 송신된 때 타이머를 시작할 수 있다. 단계 (1320)에서, 네트워크 어댑터 디바이스는 타이머가 만료되었는지를 결정할 수 있다. 타이머가 만료된 때, 네트워크 어댑터 디바이스는 미리 발송된 하나 이상의 패킷들을 재발송할 수 있다. 네트워크 어댑터 디바이스는 또한 네트워크상에 목적지로 패킷들을 발송하기 위해 사용되는 경로들을 변경하는 것과 같은 다른 동작들을 취할 수 있다.

도 14는 패킷이 수신된 것을 표시하기 위해 각각의 패킷에 대한 응답들을 생성하고고 네트워크를 통하여 패킷들을 수신하기 위한 프로세스(1400)의 예를 예시한다. 예제 프로세스 (1400)는 커널 바이패스 프레임워크를 구현하도록 구성된 네트워크 어댑터 디바이스에 의해 실행될 수 있다. 일부 구현예들에서, 네트워크 어댑터 디바이스는 완화된 신뢰할 수 있는 데이터그램 전송 서비스를 이용하여 패킷들을 수신하고 응답들을 생성할 수 있다.

단계 (1402)에서, 네트워크 어댑터 디바이스는 수신 큐에서 패킷들을 수신할 수 있고, 여기서 패킷들은 순서가 바뀌어서 수신된다. 패킷들은 네트워크를 통하여 수신될 수 있다. 수신 큐는 수신 큐 쌍의 일부일 수 있다. 패킷들의 순서는 각각의 패킷에 할당된 패킷 시퀀스 번호에 의해 결정될 수 있다. 패킷들은 패킷 시퀀스 번호들이 그것들의 숫자 순서대로 있지 않은 때(예를 들어, 최저 내지 최고), 또는 패킷 시퀀스 번호들이 시퀀스로부터 누락되기 때문에 (예를 들어, 패킷들은 시퀀스 번호들 “1, 3”을 가진다) 순서가 바뀔 수 있다.

각각의 패킷 수신시, 네트워크 어댑터 디바이스는 단계 (1404)에서, 패킷들과 관련된 전송 컨텍스트를 식별할 수 있다. 네트워크 어댑터 디바이스는 각각의 패킷에 제공된 소스 어드레스로부터 전송 컨텍스트를 식별할 수 있다. 식별된 전송 컨텍스트는 패킷들을 발송하는 소스 시스템과 연결을 관리할 수 있다. 전송 컨텍스트는 또한 특정 소스 시스템으로부터 들어오는 패킷들에 대한 상태를 모니터링할 수 있다.

단계 (1405)에서, 네트워크 어댑터 디바이스는 패킷이 수락될 수 있는지 여부를 결정할 수 있다. 네트워크 어댑터 디바이스는 예를 들어, 패킷을 둘 호스트 디바이스에서 이용 가능한 메모리가 없을 때 패킷을 수락할 수없다고 결정할 수 있고, 어떠한 버퍼들도 패킷들을 수신하는데 이용 가능하지 않다는 것을 의미한다. 이것은 수신 유저 애플리케이션이 패킷들을 수신하는데 충분한 메모리를 할당하지 않았거나, 및/또는 충분히 빠르게 메모리를 비우지 않은 때 발생할 수 있다. 일부 경우들에서, 발송 유저 애플리케이션은 일부 경우들에서, 발송 유저 애플리케이션이 패킷들을 송신하는 비율을 축소할 수 있다는 것을 통지 받을 필요가 있다. 대안적으로 또는 추가적으로, 네트워크 어댑터 디바이스는 패킷이 복제되었다는 것을 결정할 수 있다. 대안적으로 또는 추가적으로, 네트워크 어댑터 디바이스는 패킷이 유효하지 않는다(invalid)는 것을 결정할 수 있다. 예를 들어, 만약 그것이 유효한 어드레스를 가지지 않고, 부정확하게 어드레스 지정되고, 붕괴되고(corrupted), 및/또는 유효하지 않은 것으로 수신 전에 마킹된다면 패킷은 유효하지 않을 수 있다. 이 예에서, 네트워크 어댑터 디바이스는 단계 (1405)에서, 패킷이 수락될 수 있는지를 결정한다.

단계 (1406)에서, 네트워크 어댑터 디바이스는 식별된 전송 컨텍스트 및 수신 큐의 아이덴티티를 이용하여, 패킷들을 수신할 유저 애플리케이션을 결정할 수 있다. 전송 컨텍스트는 그것들의 목적지를 결정하기 위해 패킷들을 조사할 수 있다. 예를 들어, 패킷들은 목적지 어드레스를 가질 수 있고 이 목적지 어드레스는 패킷들을 수신할 유저 애플리케이션을 적어도 부분적으로 식별할 수 있다. 수신 큐의 아이덴티티는 또한, 어느 정도는, 패킷들을 수신할 유저 애플리케이션을 식별할 수 있다. 수신 큐의 아이덴티티는 다수의 큐 쌍들 중에서 수신 큐를 식별하기 위해 네트워크 어댑터에 의해 사용되는 문자와 숫자 값일 수 있다.

단계 (1408)에서, 네트워크 어댑터 디바이스는 수신된 패킷들을 수신 큐로부터 수신 유저 애플리케이션와 관련된 호스트 메모리내 버퍼로 전송할 수 있다. 네트워크 어댑터 디바이스는 수신 유저 애플리케이션에 할당된 메모리에 대한 등록 키들을 가질 수 있다. 네트워크 어댑터 디바이스는 수신 유저 애플리케이션에 할당된 메모리에 패킷들을 직접 기록하기 위해 등록 키들을 사용할 수 있다. 수신 유저 애플리케이션은 네트워크로부터 패킷들을 수신하려고 미리 이 메모리내 버퍼들을 구성할 수 있다.

일부 구현예들에서, 네트워크 어댑터 디바이스는 하나 이상의 패킷들 프로세싱시에 적어도 세개의 응답 유형들 중 하나를 송신할 수 있다. 전송 컨텍스트는 플로우(flow)내 패킷들의 상태를 모니터링할 수 있고, 적절한 응답을 제공할 수 있다.

첫번째, 단계 (1410)에서, 네트워크 어댑터 디바이스는 하나 이상의 패킷들이 수신되었다는 것을 나타내는 응답을 송신할 수 있다. 일부 구현예들에서, 이 응답은 하나 이상의 패킷들이 순서에 맞게 수신되었다는 것을 표시하고, 여기서 순서는 각각의 패킷에 할당된 패킷 시퀀스 번호들에 의해 제공되고, 여기서 어떠한 패킷들도 시퀀스로부터 누락되지 않는다. 예를 들어, 응답은 “3”을 말할 수 있고, 이는 패킷들 번호들 1, 2, 및 3이 수신되었다는 것을 나타낸다.

두번째, 단계 (1412)에서, 네트워크 어댑터 디바이스는 하나 이상의 패킷들이 수신되지 않았다는 것을 나타내는 응답을 송신할 수 있다. 일부 구현예들에서, 이 응답 메시지는 도달한 패킷들의 패킷 시퀀스 번호들을 제공할 수 있고, 시퀀스 번호들에서의 갭에 의해 도달하지 않은 패킷들을 표시할 수 있다. 예를 들어, 응답에서 패킷 시퀀스 번호들 “1, 3”은 패킷 번호“2”가 도달하지 않았다는 것을 표시할 수 있다. 대안적으로, 일부 구현예들에서, 응답은 수신되지 않은 패킷들의 패킷 시퀀스 번호들을 열거할 수 있다. 예를 들어, 응답에서 패킷 시퀀스 번호들 “2-4”은 패킷들 2, 3 및 4가 아직 도달하지 않았다는 것을 표시할 수 있다.

세번째, 단계 (1414)에서, 네트워크 어댑터 디바이스는 상기에서 제공된 하나 이상의 이유들 때문에 다른 패킷이 수락될 수 없다고 결정할 수 있다. 이 패킷이 수락될 수 없다고 결정한 때, 네트워크 어댑터 디바이스는 단계 (1416)에서 패킷을 드랍할 수 있다. 네트워크 어댑터는 옵션으로 그런다음, 단계 (1418)에서, 패킷이 재발송될 것을 나타내는 응답을 네트워크를 통하여 발송할 수 있다. 이 응답은 패킷이 도달하였지만, 그러나 패킷이 수락될 수 없고 따라서 재송신될 필요가 있다는 것을 소스 시스템에 표시할 수 있다.

IV. 네트워크 어댑터 디바이스

도 15는 상기에서 설명된 시스템들 및 방법들을 구현하기 위해 사용될 수 있는 네트워크 어댑터 디바이스(1500)의 예를 예시한다. 이 예에서, 네트워크 어댑터 디바이스(1500)는 프로세싱 코어들(1502), 구성 모듈(1504), 관리 모듈(1506), 버스 인터페이스 모듈(1508), 메모리(1510) 및 네트워크 인터페이스 모듈(1512)을 포함할 수 있다. 이러한 모듈들은 하드웨어 모듈, 소프트웨어 모듈 또는 하드웨어와 소프트웨어의 조합일 수 있다. 네트워크 어댑터 디바이스(1500)는 여기에 도시되지 않은 추가 모듈들을 포함할 수 있다. 일부 구현 예들에서, 네트워크 어댑터 디바이스(1500)는 보다 적은 모듈을 포함할 수 있다. 모듈들 중 하나 이상은 통신 채널 (1514)을 통하여 서로 통신할 수 있다. 통신 채널 (1514)은 하나 이상의 버스들은, 메시들, 매트릭스들, 패브릭들, 이들 통신 채널들의 조합, 또는 일부 다른 적절한 통신 채널을 포함할 수 잇다. 일부 구현예들에서, 네트워크 어댑터 디바이스 (1500)의 동작들이 단일 집적 회로로, 또는 집적 회로들의 그룹으로 구현될 수 있다. 집적 회로들의 예들은 ASIC들 및 FPGA들을 포함한다.

일부 구현예들에서, 프로세싱 로직(1502)은 지시들을 실행하도록 구성된 하나 이상의 프로세서들을 포함할 수 있다. 프로세싱 코어들(1502)에 포함될 수 있는 프로세서들의 예는 ARM, MIPS, AMD, Intel, Qualcomm 등에 의해 개발된 프로세서를 포함한다. 일부 구현 예들에서, 프로세싱 코어(1502)의 프로세서들은 예를 들어 버스들(busses), 레벨 (1L1) 캐시들(caches), 및/또는 레벨 2(L2) 캐시들과 같은 특정 리소스들을 공유할 수 있다. 프로세싱 코어(1502)에 의해 실행되는 지시들은 컴퓨터 판독 가능 저장 매체 상에, 예를 들어 컴퓨터 프로그램의 형태로 저장될 수 있다. 컴퓨터 판독 가능 저장 매체는 비-일시적일 수 있다. 일부 경우들에서, 컴퓨터 판독가능한 매체는 메모리 (1510)의 일부일 수 있다. 일부 구현예들에서, 프로세싱 코어들 (1502)의 동작들은 (때때로 그러나 프로세싱 코어들 (1502)에 의해 실행되는 지시들의 일부 또는 전부를 항상 포함하지 않는다) 하나 이상의 집적 회로들로 구현될 수 있다. 집적 회로들의 예들은 ASIC들 및 FPGA들을 포함한다.

메모리(1510)는 휘발성 또는 비-휘발성, 또는 휘발성 및 비-휘발성 유형의 메모리 모두를 포함할 수 있다. 메모리(1510)는 예를 들어, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 전기적으로 소거 가능한 프로그램 가능 판독 전용 메모리(EEPROM), 플래시 메모리 및/또는 다른 적절한 저장 매체를 포함할 수 있다. 일부 경우에, 메모리(1510)의 일부 또는 전부는 네트워크 어댑터 디바이스(1500)의 내부에 있을 수 있는 반면, 다른 경우에는 메모리의 일부 또는 전부는 네트워크 어댑터 디바이스(1500) 외부에 있을 수 있다.

일부 구현 예들에서, 구성 모듈(1504)은 하나 이상의 구성 레지스터들을 포함할 수 있다. 구성 레지스터들은 네트워크 어댑터 디바이스(1500)의 동작을 제어할 수 있다. 일부 구현 예들에서, 구성 레지스터 내의 하나 이상의 비트들은 네트워크 어댑터 디바이스(1500)의 특정 성능을 나타낼 수 있다. 구성 레지스터들는 프로세싱 코어(1502)에서 실행되는 지시들 및/또는 호스트 디바이스, 호스트 디바이스에서 실행되는 운영 체제, 및/또는 원격 서버와 같은 외부 엔티티에 의해 프로그래밍될 수 있다. 구성 모듈(1504)은 네트워크 어댑터 디바이스(1500)의 동작을 제어하는 하드웨어 및/또는 소프트웨어를 더 포함할 수 있다.

일부 구현 예에서, 관리 모듈(1506)은 네트워크 어댑터 디바이스(1500)의 상이한 컴포넌트들을 관리하도록 구성될 수 있다. 일부 경우에 있어서, 관리 모듈(1506)은 전원을 켤 때 하나 이상의 구성 레지스터에 하나 이상의 비트를 구성하여 네트워크 어댑터 디바이스(1500)의 특정 기능을 활성화 또는 비활성화할 수 있다.

버스 인터페이스 모듈(1508)은 외부 통신 매체를 통해 호스트 시스템 및/또는 컴퓨팅 시스템 내의 다른 컴포넌트와 같은 외부 엔티티와의 통신을 가능하게 할 수 있다. 버스 인터페이스(1508) 모듈은 케이블, 소켓, 포트, 또는 외부 통신 매체에 대한 다른 접속에 접속하기 위한 물리적 인터페이스를 포함할 수 있다. 버스 인터페이스 모듈(1508)은 수신 및 발신 트랜잭션들을 관리하기 위한 하드웨어 및/또는 소프트웨어를 더 포함할 수 있다. 버스 인터페이스(1508) 모듈은 NVMe, AHCI, SCSI, SAS, SATA, PATA, 등과 같은 로컬 버스 프로토콜을 구현할 수 있다. 버스 인터페이스(1508) 모듈은 적어도 커넥터, 전력 관리, 에러 핸들링 등을 포함하는 이들 버스 프로토콜들 중 임의의 것에 대한 물리 계층을 포함할 수 있다. 일부 구현 예들에서, 네트워크 어댑터 디바이스(1500)는 다수의 외부 엔티티들과 통신하기 위한 다수의 버스 인터페이스 모듈들을 포함할 수 있다. 이러한 다중 버스 인터페이스 모듈들은 동일한 로컬 버스 프로토콜, 상이한 로컬 버스 프로토콜, 또는 동일 및 상이한 버스 프로토콜의 조합을 구현할 수 있다.

네트워크 인터페이스 모듈(1512)은 네트워크와 통신하기 위한 하드웨어 및/또는 소프트웨어를 포함할 수 있다. 이 네트워크 인터페이스 모듈(1512)은 예를 들어, 네트워크로의 유선 접속을 위한 물리적 커넥터 및/또는 네트워크로의 무선 통신을 위한 안테나를 포함할 수 있다. 네트워크 인터페이스 모듈(1512)은 네트워크 프로토콜 스택을 구현하도록 구성된 하드웨어 및/또는 소프트웨어를 더 포함할 수 있다. 네트워크 인터페이스 모듈(1512)은 예를 들어 TCP/IP, Infiniband, RoCE, IEEE 802.11 무선 프로토콜, UDP(User Datagram Protocol), 비동기식 전송 모드(ATM), 토큰 링, 프레임 릴레이, HDLC(High Level Data Link Control), FDDI(Fiber Distributed Data Interface) 및/또는 PPP(Point-to-Point Protocol) 등과 같은 네트워크 프로토콜을 사용하여 네트워크와 통신할 수 있다. 일부 구현 예에서, 네트워크 어댑터 디바이스(1500)는 각각 다른 네트워크와 통신하도록 구성된 다중 네트워크 인터페이스 모듈들을 포함할 수 있다. 예를 들어, 이러한 구현에서, 네트워크 어댑터 디바이스(1500)는 유선 이더넷 네트워크, 무선 802.11 네트워크, 셀룰러 네트워크, Infiniband 네트워크 등과 통신하기 위한 네트워크 인터페이스 모듈을 포함할 수 있다.

일부 구현 예들에서, 네트워크 어댑터 디바이스(1500)는 PCI-유형 디바이스이다. 이들 구현예들에서, 네트워크 어댑터 디바이스 (1500)는 호스트 디바이스와 통신하기 위한 PCI 인터페이스를 포함한다. 용어 “PCI” 원래의 PCI 표준, PCI-X, AGP, 및 PCIe를 포함하는 버스 프로토콜들의 PCI 패밀리내 임의의 프로토콜을 설명하기 위해 사용될 수 있다. PCI 프로토콜들은 로컬 주변 디바이스들울 호스트 디바이스들에 연결하기 위한 표준 버스 프로토콜들이다. 표준화된 버스 프로토콜은 사양이 정의되고 다양한 제조자들에 의해 채택된 데이터 전송 프로토콜이다. 제조자들은 호환(compliant) 디바이스들이 버스 프로토콜을 컴퓨팅 시스템들과 호환 가능하고, 반대인 것을 보장한다.

PCI 디바이스는 하나 이상의 기능들을 포함할 수 있다. “기능(function)”은 네트워크 어댑터 디바이스 (1500)에 의해 제공될 수 있는 동작들을 설명한다. 기능들의 예들은 그 중에서도 대용량 스토리지 제어기들, 네트워크 제어기들, 디스플레이 제어기들, 메모리 제어기들, 직렬 버스 제어기들, 무선 제어기들, 및 암호화 및 복호화 제어기들을 포함한다. 일부 경우들에서, PCI 디바이스는 하나 초과의 기능을 포함할 수 있다. 예를 들어, PCI 디바이스는 대용량스토리지 제어기 및 네트워크 어댑터를 제공할 수 있다. 다른 예로서, PCI 디바이스는 두개의 상이한 스토리지 자원들을 제어하기 위한 두개의 스토리지 제어기들을 제공할 수 있다. 일부 구현예들에서, PCI 디바이스는 여덟개 까지의 기능들을 가질 수 있다.

일부 구현 예들에서, 네트워크 어댑터 디바이스(1500)는 SR-IOV(single-root I/O virtualization)을 포함할 수 있다. SR-IOV는 PCI 디바이스에 포함될 수 있는 확장된 성능이다. SR-IOV는 물리적 자원 (예를 들어, 단일 네트워크 인터페이스 제어기)이 다수의 자원들 (예를 들어, 64 네트워크 인터페이스 제어기들)처럼 보이는 것을 허용한다. 따라서, 어떤 기능 (예를 들어, 네트워크 인터페이스 제어기)를 제공하는 PCI 디바이스는 PCI 디바이스를 사용하는 디바이스를 동일 기능을 제공하는 다수의 디바이스들이도록 보이게 할 수 있다. SR-IOV-가능한 스토리지 어댑터 디바이스의 기능들은 물리적 기능들 (PF들) 또는 가상 기능들 (VF들)로 분류될 수 있다. 물리적 기능들은 발견되고, 관리되고, 및 조작될 수 있는 디바이스의 완전히 특징화된 기능들이다. 물리적 기능들은 스토리지 어댑터 디바이스를 제어 또는 구성하기 위해 사용될 수 있는 구성 자원들을 가진다. 물리적 기능들은 비-가상화된 디바이스가 가질 동일한 구성 어드레스 스페이스 및 메모리 어드레스 스페이스를 포함한다. 물리적 기능은 그것과 관련된 많은 가상 기능들을 가질 수 있다. 가상 기능들은 물리적 기능들에 유사하지만, 그러나 구성 자원들이 부족한 경량 기능들이고, 일반적으로 그것들의 하지의 물리적 기능들의 구성에 의해 제어된다. 각각의 물리적 기능들 및/또는 가상 기능들은 호스트 디바이스상에서 운용하는 실행 (예컨대 예를 들어, 가상 기계)의 개별 스레드(thread)에 할당될 수 있다.

V. 컴퓨팅 시스템(COMPUTING SYSTEMS)

도 16은 본 출원에서 설명된 특징부들 및 시스템들에 대한 예제 아키텍처 (1600)를 예시한다. 예제 아키텍처(1600)은 하나 이상의 네트워크들(1608)들을 통해 연결된 하나 이상의 서비스 제공자 컴퓨터(1610)들 및/또는 유저 디바이스(1604)들을 포함한다. 상기에서 설명된 시스템들 및 방법들은 도 16에 설명된 컴퓨팅 디바이스들의 하나 이상의 컴포넌트들을 사용할 수도 있거나, 또는 도 16에 설명된 하나 이상의 컴퓨팅 디바이스들을 나타낼 수 있다.

도시된 아키텍처(1600)에서, 한 명 이상의 유저(1602)는, 하나 이상의 네트워크(1608)를 통해 애플리케이션(1606)(예를 들어, 웹 브라우저 또는 모바일 디바이스 애플리케이션)에 액세스하기 위해 유저 컴퓨팅 디바이스들(1604(1)-(N))을 사용할 수 있다. 일부 양태들에서, 애플리케이션(1606)은 컴퓨팅 자원 서비스 또는 서비스 제공자에 의해 호스팅, 관리 및/또는 제공될 수 있다. 하나 이상의 서비스 제공자 컴퓨터(1610)는, 유저(들)(1602)이 상호작용할 수 있는 유저 디바이스(1604)에서 동작하도록 구성된 네이티브 애플리케이션을 제공할 수 있다. 일부 예들에서, 서비스 제공자 컴퓨터(들)(1610)는, 저-레이턴시 데이터 저장, 내구성 데이터 저장, 데이터 액세스, 관리, 가상화, 클라우드 기반 소프트웨어 솔루션, 전자 컨텐츠 성능 관리 등의 컴퓨팅 자원들을 제공할 수 있지만, 이에 한정되지 않는다. 서비스 제공자 컴퓨터(들)(1610)는, 또한, 웹 호스팅, 데이터베이싱, 컴퓨터 애플리케이션 개발 및/또는 구현 플랫폼, 전술한 것들의 조합 등을 유저(들)(1602)에게 제공하도록 동작할 수 있다. 일부 예들에서, 서비스 제공자 컴퓨터(들)(1610)는 하나 이상의 제3자 컴퓨터(1612)와 통신할 수 있다.

일부 예들에서, 네트워크(들)(1608)는, 케이블 네트워크, 인터넷, 무선 네트워크, 셀룰러 네트워크, 및 다른 개인 및/또는 공용 네트워크들 등의 서로 다른 많은 유형의 네트워크들 중 임의의 하나 또는 조합을 포함할 수 있다. 도시된 예는 네트워크(들)(1608)를 통해 애플리케이션(1606)에 액세스하는 유저(들)(1602)를 나타내고 있지만, 설명된 기술들은, 유저(들)(1602)가 유선 전화선을 거친 유저 디바이스(들)(1604)를 통해, 키오스크(kiosk)를 통해, 또는 다른 임의의 방식으로 서비스 제공자 컴퓨터(들)(1610)와 상호작용하는 경우에 적용될 수 있다. 또한, 설명된 기술들은 또한 넌-클라이언트/서버 디바이스(예컨대, 로컬에 저장된 애플리케이션 등)뿐만 아니라 다른 클라이언트/서버 디바이스(예를 들어, 셋톱 박스 등)에도 적용될 수 있다.

간략하게 설명된 바와 같이, 애플리케이션(1606)은, 유저(들)(1602)이 예를 들어 웹 컨텐츠(예를 들어, 웹 페이지, 음악, 비디오 등)를 액세스하기 위해 서비스 제공자 컴퓨터(1610)와 상호 작용하는 것을 허용할 수 있다. 서버들의 클러스터로 또는 서버 팜으로서 배열될 수 있는 서비스 제공자 컴퓨터(들)(1610)는 애플리케이션(1606) 및/또는 클라우드 기반 소프트웨어 서비스를 호스팅할 수 있다. 다른 서버 아키텍처들은, 애플리케이션(1606)을 호스팅하는 데 사용될 수 있다. 애플리케이션(1606)은 많은 유저들(1602)로부터의 요청을 처리할 수 있고, 예를 들어, 이에 응답하여 다양한 아이템 웹 페이지들을 제공할 수 있다. 애플리케이션(1606)은, 소셜 네트워킹 사이트, 온라인 소매업체, 정보 사이트, 블로그 사이트, 검색 엔진 사이트, 뉴스 및 엔터테인먼트 사이트 등을 포함하는 유저 상호작용을 지원하는 임의의 유형의 웹사이트를 제공할 수 있다. 상술한 바와 같이, 설명된 기술들은, 유저 디바이스(들)(1604)에서 실행되고 있는 다른 애플리케이션들과 같이 애플리케이션(1606)의 외부에서 유사하게 구현될 수 있다.

유저 디바이스(들)(1604)는, 예컨대, 예를 들어 이동 전화, 스마트폰, PDA(개인 정보 단말기), 랩톱 컴퓨터, 노트북 컴퓨터, 데스크톱 컴퓨터, 씬 클라이언트(thin-client) 디바이스, 태블릿 PC, 전자 서적(e-book) 리더기, 게임 콘솔, 등의 컴퓨팅 디바이스일 수 있다. 일부 예들에서, 유저 디바이스(들)(1604)는, 네트워크(1608)를 통해 또는 다른 네트워크 접속을 통해 서비스 제공자 컴퓨터(들)(1610)와 통신할 수 있다. 또한, 유저 디바이스(들)(1604)는, 서비스 제공자 컴퓨터(들)(1610)(예를 들어, 서비스 제공자 컴퓨터(1610)와 통합된 콘솔 디바이스)에 의해 관리되고 제어되는 분산형 시스템의 일부일 수도 있거나 또는 그렇지 않으면 그 서비스 제공자 컴퓨터들의 일부일 수 있다.

일 예제 구성에 있어서, 유저 디바이스(들)(1604)는, 적어도 하나의 메모리(1614) 및 하나 이상의 처리 유닛(또는 프로세서(들)(1616))을 포함할 수 있다. 프로세서(들)(1616)는 하드웨어, 컴퓨터 실행가능 지시, 펌웨어, 또는 이들의 조합으로 구현될 수 있다. 프로세서(들)(1616)의 컴퓨터 실행가능 지시들 또는 펌웨어 구현은, 기술된 다양한 기능들을 수행하기 위해 임의의 적절한 프로그래밍 언어로 작성된 컴퓨터 실행가능 또는 기계 실행가능 지시들을 포함할 수 있다. 유저 디바이스(들)(1604)는, 또한, 유저 디바이스(들)(1604)에 연관된 지리적 위치 정보를 제공 및/또는 기록하기 위한 지리적 위치 디바이스(예를 들어, 글로벌 위치확인 시스템(GPS) 디바이스 등)를 포함할 수 있다.

유저 디바이스 메모리(1614)는, 유저 디바이스 프로세서(들)(1616) 상에 로딩될 수 있고 실행가능한 프로그램 지시들 및 이들 프로그램의 실행 동안 생성된 데이터를 저장할 수 있다. 유저 디바이스(들)(1604)의 구성 및 유형에 따라, 유저 디바이스 메모리(1614)는 (RAM 등의) 휘발성 및/또는 (ROM, 플래시 메모리 등의) 비휘발성일 수 있다. 유저 디바이스(들)(1604)는, 또한, 자기 스토리지, 광 디스크, 고체 상태 디스크들, 플래시 메모리 및/또는 테이프 스토리지를 포함하지만 이에 제한되지 않는 추가 탈착가능 스토리지 및/또는 탈착불가 스토리지를 포함할 수 있다. 스토리지 드라이브들 및 이에 연관된 컴퓨터 판독가능 매체는 컴퓨팅 디바이스에 대한 컴퓨터 판독가능 지시, 데이터 구조, 프로그램 모듈, 및 기타 데이터의 비휘발성 스토리지를 제공할 수 있다. 일부 구현예들에서, 메모리(1614)는, SRAM, DRAM, 또는 ROM 등의 서로 다른 다수의 유형의 메모리를 포함할 수 있다.

더 상세하게 유저 디바이스 메모리(1614)의 컨텐츠로 가서, 메모리(1614)는 본 개시의 특징을 구현하기 위한 운영 체제, 및 하나 이상의 애플리케이션 프로그램 또는 서비스를 포함할 수 있다. 하나 이상의 애플리케이션 프로그램들 또는 서비스들은 적어도 유저 제공 입력 엘리먼트 또는 전자 서비스 웹 페이지 예컨대, 브라우저 애플리케이션 (1606) 또는 전용 애플리케이션들(예를 드렁, 스마트폰 애플리케이션들, 태블릿 애플리케이션등)을 포함할 수 있다. 브라우저 애플리케이션(1606)은, 서비스 제공자 컴퓨터(들)(1610)와 상호작용하기 위한 웹사이트 또는 다른 인터페이스를 수신, 저장, 및/또는 표시하도록 구성될 수 있다. 또한, 메모리(1614)는, 유저 ID, 패스워드, 및/또는 다른 유저 정보 등의 액세스 증명서 및/또는 다른 유저 정보를 저장할 수 있다. 일부 예들에서, 유저 정보는, 계정 액세스 요청을 인증하기 위한 정보를 포함할 수 있다. 이런 정보는 예를 들어, 디바이스 ID, 쿠키, IP 어드레스, 위치, 또는 유사한 것을 포함한다. 또한, 유저 정보는, 보안 질문에 대한 유저 제공 응답 또는 유저 디바이스(1604)에 의해 취득된 지리적 위치를 포함할 수 있다.

일부 양태들에서, 서비스 제공자 컴퓨터(들)(1610)는, 또한, 이동 전화, 스마트폰, 개인 정보 단말기(PDA), 랩톱 컴퓨터, 데스크톱 컴퓨터, 서버 컴퓨터, 노트북 컴퓨터, 서버 컴퓨터, 씬 클라이언트 디바이스, 태블릿 컴퓨터, 게임 콘솔 등의 컴퓨팅 디바이스를 포함할 수 있다. 추가적으로 또는 대안적으로, 일부 실시예들에서, 서비스 제공자 컴퓨터(들)(1610)는 호스팅된 컴퓨팅 환경에서 구현되는 하나 이상의 가상 기계들로서 제공될 수 있다. 호스팅된 컴퓨팅 환경은 하나 이상의 신속하게 프로비저닝되고 릴리즈된 컴퓨팅 자원들을 포함할 수 있다. 이들 컴퓨팅 자원들은 컴퓨팅, 네트워킹 및/또는 스토리지 디바이스들을 포함할 수 있다. 호스팅된 컴퓨팅 환경은 또한 클라우드 컴퓨팅 환경이라고 할 수 있다. 일부 예들에서, 서비스 제공자 컴퓨터(들)(1610)는, 네트워크(들)(1608)를 통해 또는 다른 네트워크 접속을 통해 유저 디바이스(들)(1604) 및/또는 다른 서비스 제공자들과 통신할 수 있다. 서비스 제공자 컴퓨터(들)(1610)는, 아마도 클러스터 내에, 서버 팜으로서, 또는 서로 연관되지 않은 개별 서버들로서 배열된 하나 이상의 서버를 포함할 수 있다. 이러한 서버들은, 통합 분산형 컴퓨팅 환경의 일부로서 구성될 수 있다.

예시적인 한 구성에 있어서, 서비스 제공자 컴퓨터(들)(1610)는, 적어도 하나의 메모리(1618) 및 하나 이상의 처리 유닛(또는 프로세서(들) (1620))을 포함할 수 있다. 프로세서(들)(1620)는 하드웨어, 컴퓨터 실행가능 지시, 펌웨어, 또는 이들의 조합으로 구현될 수 있다. 프로세서(들)(1620)의 컴퓨터 실행가능 지시들 또는 펌웨어 구현은, 기술된 다양한 기능들을 수행하기 위해 임의의 적절한 프로그래밍 언어로 작성된 컴퓨터 실행가능 또는 기계 실행가능 지시들을 포함할 수 있다.

일부 경우에, 하드웨어 프로세서(들)(1620)는 단일 코어 프로세서 또는 멀티 코어 프로세서일 수 있다. 멀티 코어 프로세서는 동일한 프로세서 내에 다수의 처리 유닛들을 포함할 수 있다. 일부 실시예에서, 멀티 코어 프로세서들은, 제2레벨 또는 제3레벨 캐시들과 버스 등의 소정의 자원들을 공유할 수 있다. 일부 경우에, 단일 코어 또는 멀티 코어 프로세서의 각 코어는, 또한, 다중 실행 로직 프로세서(또는 실행 스레드)를 포함할 수 있다. (예를 들어, 다중 로직 프로세서들을 갖는) 이러한 코어에서는, 실행 파이프 라인의 여러 단계들과 하위 수준 캐시들도 공유될 수 있다.

메모리(1618)는, 프로세서(들)(1620) 상에 로딩될 수 있고 실행가능한 프로그램 지시들 및 이들 프로그램의 실행 동안 생성된 데이터를 저장할 수 있다. 서비스 제공자 컴퓨터(들)(1610)의 구성 및 유형에 따라, 메모리(1618)는 (RAM 등의) 휘발성 및/또는 (ROM, 플래시 메모리 등의) 비휘발성일 수 있다. 메모리(1618)는 본 개시의 특징을 구현하기 위한 운영 체제(1628), 하나 이상의 데이터 저장소들(1630), 및/또는 하나 이상의 애플리케이션 프로그램(1632), 하나 이상의 드라이버들(1634) 또는 서비스를 포함할 수 있다.

운영 체제 (1628)는 서비스 제공자 컴퓨터의 (1610) 기본 기능들, 예컨대 스케줄링 태스크들, 실행 애플리케이션들, 및/또는 제어기 주변 디바이스들을 기원할 수 있다. 일부 구현예들에서, 서비스 제공자 컴퓨터 (1610)는 하나 이상의 가상 기계들을 호스트할 수 있다. 이들 구현예들에서, 각각의 가상 기계는 그것 자체의 운영 체제를 실행하도록 구성될 수 있다. 운영 체제들의 예들은 Unix, 리눅스, 윈도우들, Mac OS, iOS, 안드로이드, 및 유사한 것을 포함한다. 운영 체제 (1628)는 또한 전용 운영 체제일 수 있다.

데이터 저장소 (1630)은 운영 체제 (1628), 애플리케이션 프로그램들 (1632), 또는 드라이버들 (1634)에 의해 사용되고 및/또는 그것들 상에서 운용되는 영구적인 또는 일시적 데이터를 포함할 수 있다. 이런 데이터의 예들은 웹 페이지들, 비디오 데이터, 오디오 데이터, 이미지들, 유저 데이터, 등등을 포함한다. 데이터 저장소 (1630)에 정보는 일부 구현예들에서, 네트워크(들) (1608)를 통하여 유저 디바이스들 (1604)에 제공될 수 있다. 일부 경우들에서, 데이터 저장소 (1630)는 추가적으로 또는 대안적으로 저장된 애플리케이션 프로그램들 및/또는 드라이버들을 포함할 수 있다. 대안적으로 또는 추가적으로, 데이터 저장소 (1630)는 표준 및/또는 전용 소프트웨어 라이브러리들, 및/또는 표준 및/또는 전용 애플리케이션 유저 인터페이스 (API) 라이브러리들을 저장할 수 있다. 데이터 저장소 (1630)에 저장된 정보는 기계-판독가능한 오브젝트 코드, 소스 코드, 기계 번역된 코드, 또는 매개 코드일 수 있다.

애플리케이션 프로그램들 (1632)은 네트워크(들) (1608)을 통하여 유저 디바이스들 (1604)에 액세스 가능한 프로그램들을 포함할 수 있다. 이런 프로그램들의 예들은 워드 프로세싱 프로그램들, 회계(accounting) 프로그램들, 미디어 플레이어들, 이미지 편집 프로그램들, 게임들, 등등을 포함한다. 애플리케이션 프로그램들 (1632)은 대안적으로 또는 추가적으로 클러스터링 또는 분배 환경에서 실행되는 프로그램들, 즉, 다수의 서버 제공자 컴퓨터들 (1610)간에 협력하여 실행되는 애플리케이션들을 포함할 수 있다.

드라이버들 (1634)은 서버 제공자 컴퓨터 (1610)에서 컴포넌트들간에 통신을 제공할 수 있는 프로그램들을 포함한다. 예를 들어, 일부 드라이버들 (1634)는 운영 체제 (1628)와 추가의 스토리지 (1622), 통신 연결들 (1624), 및/또는 I/O 디바이스 (1626)간에 통신을 제공할 수 있다. 대안적으로 또는 추가의, 일부 드라이버들 (1634)은 애플리케이션 프로그램들 (1632) 및 운영 체제 (1628), 및/또는 애플리케이션 프로그램들 (1632) 및 서비스 제공자 컴퓨터 (1610)에 액세스 가능한 주변 디바이스들 사이에서 통신을 제공할 수 있다. 많은 경우들에서, 드라이버들 (1634)는 잘 알려진 기능 (예를 들어, 프린터 드라이버들, 디스플레이 드라이버들, 하드 디스크 드라이버들)을 제공하는 드라이버들을 포함할 수 있다. 다른 경우들에서, 드라이버들 (1634)는 전용 또는 특화된 기능일 수 있다.

서비스 제공자 컴퓨터(들)(1610) 또는 서버는, 또한, 탈착가능 스토리지 및/또는 탈착불가 스토리지를 포함할 수도 있는 추가 스토리지(1622)를 포함할 수 있다. 추가 스토리지 (1622)는 자기 스토리지, 광 디스크들, 고체 상태 디스크들, 플래시 메모리, 및/또는 테이프 스토리지를 포함할 수 있다. 추가 스토리지 (1622)는 서비스 제공자 컴퓨터(들) (1610)와 동일한 섀시에 하우징될 수 있거나 또는 외부 인클로저에 있을 수 있다. 메모리 (1618) 및/또는 추가 스토리지 (1622) 및 그에 연관된 컴퓨터 판독가능 매체는 컴퓨팅 디바이스에 대한 컴퓨터 판독가능 지시, 데이터 구조, 프로그램 모듈, 및 기타 데이터의 비휘발성 스토리지를 제공할 수 있다. 일부 구현예들에서, 메모리(1618)는, SRAM, DRAM, 또는 ROM 등의 서로 다른 다수의 유형의 메모리를 포함할 수 있다.

탈착가능 및 탈착불가인, 메모리(1618) 및 추가 스토리지(1622)는 컴퓨터 판독가능 저장 매체의 예들이다. 예를 들어, 컴퓨터 판독가능 저장 매체는, 예를 들어, 컴퓨터 판독가능 지시, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 포함하는 정보, 해당 정보를 저장하기 위한 방법 또는 기술로 구현된 휘발성 또는 비휘발성, 탈착가능 및 탈착불가 매체를 포함할 수 있다. 메모리(1618) 및 추가 스토리지(1622)는 컴퓨터 저장 매체의 예들이다. 서비스 제공자 컴퓨터(들)(1610)에 존재할 수도 있는 추가 유형의 컴퓨터 저장 매체는, PRAM, SRAM, DRAM, RAM, ROM, EEPROM, 플래시 메모리, 또는 다른 메모리 기술, CD-ROM, DVD, 또는 다른 광학 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지, 또는 다른 자기 스토리지, 고체 상태 드라이브들 또는 원하는 정보를 저장하는 데 사용될 수 있고 서비스 제공자 컴퓨터(들)(1610)에 의해 액세스될 수 있는 일부 다른 매체를 포함할 수 있지만, 이러한 예들에 한정되지 않는다. 컴퓨터 판독 가능한 매체는 또한 임의의 상기 매체 유형들의 조합들을 포함한다.

대안으로 또는 추가적으로, 컴퓨터 판독가능 통신 매체는, 반송파 또는 다른 전송과 같이 데이터 신호 내에서 송신되는 컴퓨터 판독가능 지시, 프로그램 모듈, 또는 다른 데이터를 포함할 수 있다. 그러나, 본 명세서에서 사용되는 바와 같이, 컴퓨터 판독가능 저장 매체는 컴퓨터 판독가능 통신 매체를 포함하지 않는다.

서비스 제공자 컴퓨터(들)(1610)는, 또한, 서비스 제공자 컴퓨터(들)(1610)가 저장된 데이터베이스, 다른 컴퓨팅 디바이스 또는 서버, 유저 단말, 및/또는 네트워크(들)(1608) 상의 다른 디바이스들과 통신할 수 있게 하는 통신 접속부(들)(1624)를 포함할 수 있다. 서비스 제공자 컴퓨터(들)(1610)는, 또한, 키보드, 마우스, 펜, 음성 입력 디바이스, 터치 입력 디바이스, 디스플레이, 스피커, 프린터 등과 같은 I/O 디바이스(들)(1626)를 포함할 수 있다. 스토리지(1622)와 함께, 통신 접속부(들)(1624) 및 I/O 디바이스(들)(1626)은 주변 디바이스로 설명될 수 있다.

서비스 제공자 컴퓨터(들)(1610)는 또한 하나 이상의 통신 채널들(1634)을 포함할 수 있다. 통신 채널(1634)은 서비스 제공자 컴퓨터(1610)의 다양한 컴포넌트들이 통신할 수 있는 매체를 제공할 수 있다. 통신 채널 또는 채널들(1634)은 버스, 링, 스위칭 구조 또는 네트워크의 형태를 취할 수 있다.

본 명세서에 설명된 모듈들은 소프트웨어 모듈, 하드웨어 모듈, 또는 이들의 적절한 조합일 수 있다. 모듈이 소프트웨어 모듈인 경우, 모듈은, 비일시적 컴퓨터 판독가능 매체에서 구체화될 수 있고, 본 명세서에 설명된 컴퓨터 시스템의 프로세서에 의해 처리될 수 있다. 설명된 프로세스 및 아키텍처는 임의의 유저 상호작용 전에 실시간으로 또는 비동기 모드에서 수행될 수 있다는 점에 주목해야 한다. 모듈은 도 16에서 제안된 방식으로 구성될 수도 있고/있거나, 본 명세서에서 설명된 기능들은 개별 모듈들로서 존재하는 하나 이상의 모듈들에 의해 제공될 수 있고 및/또는 본 명세서에서 설명된 모듈 기능들은 다수의 모듈들에 걸쳐 분산될 수 있다.

도 17는 다양한 실시 예들에 따라 양태들을 구현하기 위한 예시적인 환경(1700)의 양태들을 도시한다. 인식할 수 있는 바와 같이, 웹 기반 환경이 설명을 위해 사용되지만, 다양한 환경들을 구현하도록 상이한 환경들이 적절하게 사용될 수 있다. 환경은, 적절한 네트워크(1704)를 통해 요청, 메시지, 또는 정보를 송신 및 수신하고 정보를 디바이스의 유저에게 다시 반송하도록 동작가능한 적절한 디바이스를 포함할 수 있는 전자 클라이언트 디바이스(1702)를 포함한다. 이러한 클라이언트 디바이스의 예로는, 퍼스널 컴퓨터, 휴대폰, 핸드헬드 메시징 디바이스, 랩톱 컴퓨터, 셋톱 박스, 개인 정보 단말기, 전자 북 판독기 등이 있다. 네트워크는, 인트라넷, 인터넷, 셀룰러 네트워크, 로컬 영역 네트워크, 또는 다른 임의의 이러한 네트워크 또는 이들의 조합을 포함하는 임의의 적절한 네트워크를 포함할 수 있다. 이러한 시스템에 사용되는 컴포넌트들은 선택되는 환경 및/또는 네트워크의 유형에 적어도 부분적으로 의존할 수 있다. 이러한 네트워크를 통해 통신하기 위한 프로토콜과 컴포넌트는 공지되어 있으며 본 명세서에서 상세히 설명하지 않는다. 네트워크를 통한 통신은 유선 접속 또는 무선 접속 및 이들의 조합에 의해 가능해질 수 있다. 이 예에서, 환경이 요청을 수신하고 이에 응답하여 컨텐츠를 제공하도록 웹 서버(1706)를 포함하므로 네트워크가 인터넷을 포함하지만, 다른 네트워크에 대해서는, 유사한 목적을 제공하는 대체 디바이스가 통상의 기술자에게 자명하다.

예시적인 환경은 적어도 하나의 애플리케이션 서버(1708) 및 데이터 저장소(1710)를 포함한다. 적절한 데이터 저장소로부터 데이터를 취득하는 것과 같은 작업을 수행하기 위해 상호작용할 수 있는, 여러 애플리케이션 서버들, 계층들, 또는 기타 엘리먼트들, 프로세스들 또는 컴포넌트들이 연결되거나 그 외에는 구성될 수도 있음을 이해해야 한다. 본 명세서에서 사용되는 바와 같이, "데이터 저장소"라는 용어는, 임의의 표준 환경, 분산 환경, 또는 클러스터된 환경에서 다수의 데이터 서버들, 데이터베이스들, 데이터 스토리지들, 및 데이터 저장 매체들의 임의의 개수와 조합을 포함할 수도 있는, 데이터를 저장, 액세스, 및 검색할 수 있는 임의의 디바이스 또는 디바이스들의 조합을 가리킨다. 애플리케이션 서버는, 애플리케이션을 위한 데이터 액세스와 비즈니스 로직의 대부분을 처리하는, 클라이언트 디바이스를 위한 하나 이상의 애플리케이션의 양태들을 실행하는 데 필요한 바와 같이 데이터 저장소와 통합하기 위한 임의의 적절한 하드웨어 및 소프트웨어를 포함할 수 있다. 애플리케이션 서버는, 데이터 저장소와 협력하여 액세스 제어 서비스를 제공하며, 유저에게 전송될 텍스트, 그래픽, 오디오, 및/또는 비디오와 같은 컨텐츠를 생성할 수 있으며, 이러한 컨텐츠는, 이 예에서 HTML, XML, 또는 다른 적절한 구조화된 언어의 형태로 웹 서버에 의해 유저에게 제공될 수 있다. 클라이언트 디바이스(1702)와 애플리케이션 서버(1708) 간의 컨텐츠 전달뿐만 아니라 모든 요청과 응답의 처리는 웹 서버@@06에 의해 처리될 수 있다. 본 명세서에서 논의된 구조화된 코드가 본원의 다른 곳에서 논의된 바와 같이 임의의 적절한 디바이스 또는 호스트 기계 상에서 실행될 수 있으므로, 웹(1706) 및 애플리케이션 서버(1708)는 요구되지 않으며 단지 예시적인 컴포넌트들일 뿐이라는 것을 이해해야 한다.

데이터 저장소(1710)는, 특정 양태에 관한 데이터를 저장하기 위한 몇몇 별도의 데이터 테이블, 데이터베이스, 또는 다른 데이터 저장 기구 및 매체를 포함할 수 있다. 예를 들어, 도시된 데이터 저장소(1720)는, 생산측을 위한 컨텐츠를 제공하는 데 사용될 수 있는 생산 데이터(1712) 및 유저 정보(1716)를 저장하기 위한 메커니즘을 포함한다. 데이터 저장소는, 또한, 보고, 분석, 또는 이러한 다른 목적을 위해 사용될 수 있는 로그 데이터(1714)를 저장하기 위한 기구를 포함하는 것으로 도시된다. 페이지 이미지 정보 및 적절한 정보에 액세스하는 것과 같이 데이터 저장소(1710)에 저장될 필요가 있는 많은 다른 양태들이 있을 수 있으며, 이러한 정보는 데이터 저장소(1710)의 추가 기구들에 또는 적절한 경우 위에서 열거된 기구들 중 임의의 것에 저장될 수 있다는 점을 이해해야 한다. 데이터 저장소(1710)는, 애플리케이션 서버(1708)로부터 지시를 수신하고 이에 응답하여 데이터를 취득, 업데이트, 또는 그 외에는 처리하도록 연관된 로직을 통해 동작 가능하다. 일례로, 유저는 소정 유형의 항목에 대한 검색 요청을 제출할 수 있다. 이 경우, 데이터 저장소(1710)는, 유저 정보(1716)에 액세스하여 유저의 아이덴티티를 검증할 수도 있고, 카탈로그 세부 정보에 액세스하여 해당 유형의 항목에 대한 정보를 취득할 수 있다. 이어서, 정보는, 유저가 유저 디바이스(1702) 상의 브라우저를 통해 볼 수 있는 웹 페이지 상의 결과 리스트와 같이 유저에게 리턴될 수 있다. 관심있는 특정 항목에 대한 정보는 브라우저의 전용 페이지 또는 창에서 볼 수 있다.

각각의 서버(1706, 1708)는, 통상적으로 해당 서버의 일반적인 관리 및 동작을 위한 실행 가능한 프로그램 지시들을 제공하는 운영 시스템을 포함하며, 통상적으로, 서버의 프로세서에 의해 실행될 때 서버로 하여금 의도된 기능을 수행하게 하는 지시를 저장하는 컴퓨터 판독가능 저장 매체(예를 들어, 하드 디스크, 랜덤 액세스 메모리, 판독 전용 메모리 등)를 포함한다. 서버의 운영 시스템 및 일반적인 기능에 대한 적절한 구현예들은, 공지되어 있거나 상업적으로 이용가능하며, 특히 본원의 개시 내용에 비추어 볼 때 통상의 기술자에 의해 용이하게 구현된다.

일 실시 예에서의 환경(1700)은, 하나 이상의 컴퓨터 네트워크 또는 직접 접속을 이용하여 통신 링크를 통해 상호 접속되는 여러 컴퓨터 시스템들과 컴포넌트들을 이용하는 분산형 컴퓨팅 환경이다. 그러나, 통상의 기술자는, 이러한 시스템이 도 17에 도시된 것보다 적은 또는 많은 컴포넌트들을 갖는 시스템에서 동등하게 동작할 수 있음을 알 것이다. 따라서, 도 17의 시스템의 예는 본질적으로 예시적인 것이며 본 개시 내용의 범위를 제한하지 않는 것으로 취급해야 한다.

본 개시의 실시 예들은 다음의 관점에서 설명될 수 있다:

항목 1. 컴퓨팅 시스템에 있어서,

호스트 디바이스로서, 상기 호스트 디바이스는:

프로세서;

상기 프로세서들에 결합되고 상기 프로세서에 의해 판독 가능한 메모리를 포함하되, 상기 메모리는 유저 애플리케이션들을 저장하도록 구성되고; 및

네트워크와 통신하도록 구성된 네트워크 어댑터 디바이스;를 포함하고

상기 호스트 디바이스는 :

상기 유저 애플리케이션을 실행시키고, 상기 유저 애플리케이션은 :

메시지에 대하여 목적지 어드레스를 결정하고, 상기 목적지 어드레스는 상기 네트워크상에 서버와 연관되고;

상기 목적지 어드레스에 대한 어드레스 핸들(address handle)을 결정하고;

상기 메시지 및 상기 어드레스 핸들을 상기 네트워크 어댑터에 제공하도록 구성되고;

상기 네트워크 어댑터 디바이스는 :

상기 어드레스 핸들을 이용하여, 전송 컨텍스트(transport context)를 결정하고, 상기 전송 컨텍스트는 상기 목적지 어드레스와 연관된 상기 네트워크상에 서버와의 연결 상태를 포함하고;

상기 메시지 및 상기 전송 컨텍스트를 이용하여 패킷을 생성하고; 및

상기 네트워크를 통하여 상기 패킷을 송신하도록 구성된다.

항목 2. 항목 1의 컴퓨팅 시스템에 있어서, 상기 호스트 디바이스는 드라이버 프로그램을 실행시키도록 더 구성되고 상기 유저 애플리케이션은 상기 목적지 어드레스에 대한 상기 어드레스 핸들을 결정할 수 없을 때 추가로 :

상기 드라이버 프로그램으로부터 어드레스 핸들을 요청하도록 더 구성되고 상기 요청은 상기 목적지 어드레스를 포함하고;

상기 드라이버 프로그램은 :

어드레스 맵을 이용하여 상기 목적지 어드레스에 대한 어드레스 핸들(address handle)을 결정하고; 및

상기 어드레스 핸들을 상기 유저 애플리케이션에 제공하도록 구성된다.

항목 3. 항목 2의 컴퓨팅 시스템에 있어서, 상기 드라이버 프로그램은 추가로 :

상기 어드레스 맵이 상기 목적지 어드레스를 포함하지 않는다고 결정하고; 및

상기 목적지 어드레스를 상기 네트워크 어댑터 디바이스에 제공하도록 구성되고;

상기 네트워크 어댑터 디바이스는 추가로:

새로운 연결에 대한 새로운 전송 컨텍스트를 생성하고;

상기 새로운 전송 컨텍스트에 상기 새로운 연결의 상태를 저장하고;

상기 새로운 전송 컨텍스트와 새로운 어드레스 핸들을 연관시키고;

새로운 어드레스 핸들을 상기 드라이버 프로그램에 제공하고; 및

상기 목적지 어드레스와 연관된 상기 네트워크 상에 상기 서버와 상기 새로운 연결을 수립하도록 구성되고;

상기 드라이버 프로그램은 추가로:

상기 새로운 어드레스 핸들을 이용하여 상기 어드레스 맵에 상기 목적지 어드레스를 저장하도록 구성되고;

상기 결정된 전송 컨텍스트는 상기 새로운 전송 컨텍스트이고, 상기 드라이버 프로그램에 의해 제공된 상기 어드레스 핸들은 상기 새로운 어드레스 핸들이다.

항목 4. 장치에 있어서,

프로세서; 및

상기 하나 이상의 프로세서들에 결합되고 상기 프로세서들에 의해 판독 가능한 메모리를 포함하되, 상기 메모리는 복수의 전송 컨텍스트(transport context)들을 저장하도록 구성되고;

상기 장치는 :

네트워크 및 호스트 디바이스와 통신하고;

상기 호스트 디바이스로부터 메시지 및 메시지와 관련된 목적지 정보를 수신하고; 및

상기 목적지 정보를 이용하여, 상기 복수의 전송 컨텍스트들로부터 전송 컨텍스트를 결정하고, 상기 전송 컨텍스트는 상기 네트워크상에 목적지와의 연결 상태를 포함하고, 상기 네트워크상에 목적지는 상기 목적지 정보와 연관된다.

항목 5. 항목 4의 장치에 있어서, 상기 장치는 추가로:

상기 메시지 및 상기 전송 컨텍스트를 이용하여 패킷을 생성하고; 및

상기 전송 컨텍스트를 이용하여 상기 네트워크를 통하여 상기 패킷을 송신하도록 구성된다.

항목 6. 항목 4 또는 5의 장치에 있어서, 상기 목적지 정보는 어드레스 핸들(address handle)를 포함하고, 상기 장치는 추가로 :

상기 어드레스 핸들을 이용하여, 복수의 어드레스 맵 객체들로부터 네트워크 어드레스 맵 객체를 결정하도록 구성되고, 상기 복수의 어드레스 맵 객체들은 상기 메모리에 저장되고, 상기 어드레스 맵 객체는 상기 결정된 전송 컨텍스트와 연관된다.

항목 7. 항목 6의 장치에 있어서, 상기 네트워크 어드레스 맵 객체는 미리-생성된 패킷 헤더를 포함한다.

항목 8. 항목 6의 장치에 있어서, 상기 장치는 추가로:

새로운 어드레스 핸들에 대한 요청을 수신하고, 상기 요청은 상기 목적지 정보를 포함하고;

상기 새로운 목적지 정보를 이용하여, 상기 네트워크 어드레스 맵 객체를 식별하고;

상기 새로운 어드레스 핸들을 생성하도록 구성되고, 상기 새로운 어드레스 핸들은 상기 네트워크 어드레스 맵 객체와 연관되고; 및

상기 새로운 어드레스 핸들을 리턴하도록 더 구성된다.

항목 9. 항목 6의 장치에 있어서, 상기 장치는 추가로:

새로운 어드레스 핸들에 대한 요청을 수신하고, 상기 요청은 새로운 목적지 정보를 포함하고;

상기 복수의 전송 컨텍스트들이 상기 새로운 목적지 정보와 관련된 전송 컨텍스트를 포함하지 않는다고 결정한 때:

새로운 전송 컨텍스트를 생성하고; 및

상기 새로운 전송 컨텍스트에 상기 새로운 연결의 상태를 저장하고; 및

새로운 네트워크 어드레스 맵 객체를 생성하고, 상기 네트워크 어드레스 맵 객체는 상기 새로운 전송 컨텍스트와 연관되고;

상기 새로운 어드레스 핸들을 생성하고, 상기 새로운 어드레스 핸들은 상기 새로운 네트워크 어드레스 맵 객체와 연관되고; 및

상기 새로운 어드레스 핸들을 리턴하도록 구성된다.

항목 10. 항목9의 장치에 있어서, 상기 장치는 상기 복수의 전송 컨텍스트들이 상기 새로운 목적지 정보와 관련된 전송 컨텍스트를 포함하지 않는다고 결정한 때, 상기 새로운 목적지 정보와 연관된 상기 네트워크 상에 새로운 목적지를 갖는 새로운 연결을 수립하도록 더 구성된다.

항목 11. 항목 9의 장치에 있어서, 새로운 네트워크 어드레스 맵 객체를 생성하는 것은 상기 새로운 목적지 정보를 이용하여 패킷 헤더를 생성하는 것을 포함하고, 상기 생성된 패킷 헤더는 상기 새로운 네트워크 어드레스 맵 객체에 저장된다.

항목 12. 항목 4 내지 11 중 어느 하나의 장치에 있어서, 상기 장치는 상기 목적지 정보와 연관된 상기 네트워크 상의 목적지와 연결을 수립하도록 더 구성된다.

항목 13. 항목 4 내지 12 중 어느 하나의 장치에 있어서, 상기 목적지 정보는 네트워크 어드레스를 포함한다.

항목 14. 항목 4 내지 13 중 어느 하나의 장치에 있어서, 상기 목적지 정보는 플로우 식별자(flow identifier)를 포함한다.

항목 15. 항목 4 내지 14 중 어느 하나의 장치에 있어서, 상기 네트워크 상의 상기 목적지는 상기 네트워크상의 서버와 연관된다.

항목 16. 항목 4 내지 15 중 어느 하나의 장치에 있어서, 상기 네트워크 상의 상기 목적지는 하나 이상의 인터넷 프로토콜 어드레스들과 연관된다.

항목 17. 항목 4 내지 16 중 어느 하나의 장치에 있어서, 상기 네트워크 상의 상기 목적지는 인터넷 프로토콜 어드레스 및 통신 엔드 포인트 식별자와 연관된다.

항목 18. 항목 4 내지 17 중 어느 하나의 장치에 있어서, 상기 메시지는 시퀀스 식별자를 포함하고, 상기 시퀀스 식별자는 상기 메시지의 소스로부터의 다른 메시지들에 대하여 상기 메시지의 시퀀스(sequence)를 나타내고, 상기 장치는 :

상기 전송 컨텍스트를 이용하여, 상기 메시지 및 상기 메시지의 시퀀스 식별자를 포함하는 패킷을 생성하고;

상기 전송 컨텍스트를 이용하여 상기 네트워크를 통하여 상기 패킷을 송신하고;

상기 송신된 패킷에 대한 상태를 모니터링하도록 구성된다.

항목 19. 항목 4 내지 18 중 어느 하나의 장치에 있어서, 상기 장치는 네트워크 어댑터 디바이스이다.

항목 20. 항목 4 내지 19 중 어느 하나의 장치에 있어서, 상기 장치는 시스템-온-칩 (SoC), 필드-프로그램 가능한 게이트 어레이 (FPGA), 또는 애플리케이션-특정 집적 회로 (ASIC)이다.

항목 21. 장치에 있어서,

프로세서; 및

상기 하나 이상의 프로세서들에 결합되고 상기 프로세서들에 의해 판독 가능한 메모리를 포함하되, 상기 메모리는 복수의 전송 컨텍스트(transport context)들을 저장하도록 구성되고;

상기 장치는 :

네트워크와 통신하고;

상기 네트워크를 통하여 패킷을 수신하고, 상기 패킷은 상기 네트워크상의 소스와의 연결의 수립을 요청하고;

상기 네트워크 상의 상기 소스와 연관된 전송 컨텍스트(transport context)를 생성하고, 상기 전송 컨텍스트는 상기 네트워크상에 소스와의 연결 상태를 포함하고;

상기 전송 컨텍스트를 상기 메모리에 저장하고; 및

상기 네트워크 상의 상기 소스로 응답을 송신하도록 구성되고, 상기 응답은 상기 연결의 수립을 확인 응답한다.

항목 22. 항목 21의 장치에 있어서, 상기 장치는 추가로:

상기 네트워크를 통하여 제 2 패킷을 수신하고, 상기 제 2 패킷은 상기 네트워크상의 제 2 소스와의 제 2 연결의 수립을 요청하고;

상기 제 2 패킷을 이용하여 상기 전송 컨텍스트를 식별하고; 및

상기 네트워크 상의 상기 제 2 소스로 제 2 응답을 송신하도록 구성되고, 상기 제 2 응답은 상기 제 2 연결의 수립을 확인 응답한다.

항목 23. 항목 21 또는 22 의 장치에 있어서, 상기 장치는 추가로:

상기 패킷이 다른 패킷들에 대하여 수신되는 순서를 식별하고;

상기 패킷이 수락될 수 있는지 여부를 결정하고; 및

상기 패킷이 수락될 수 있다고 결정한 때:

상기 패킷에 포함된 목적지 정보를 이용하여, 수신 큐를 결정하고, 상기 수신 큐는 상기 호스트 디바이스상에 유저 애플리케이션과 연관되고;

상기 패킷을 상기 수신 큐로 전송하고; 및

상기 패킷의 상태를 나타내는 응답을 송신하도록 구성된다.

항목 24. 방법에 있어서,

네트워크 어댑터 디바이스에 의해 메시지 및 메시지와 관련된 목적지 정보를 수신하는 단계;

상기 목적지 정보를 이용하여, 복수의 전송 컨텍스트들로부터 전송 컨텍스트를 결정하는 단계를 포함하되, 상기 전송 컨텍스트는 상기 네트워크상에 목적지와의 연결 상태를 포함하고, 상기 네트워크상에 목적지는 상기 목적지 정보와 연관된다.

항목 25. 항목 24의 방법에 있어서,

상기 메시지 및 상기 전송 컨텍스트를 이용하여 패킷을 생성하는 단계; 및

상기 전송 컨텍스트를 이용하여 상기 네트워크를 통하여 상기 패킷을 송신하는 단계를 더 포함한다.

항목 26. 항목 24 또는 25의 방법에 있어서, 상기 목적지 정보는 어드레스 핸들을 포함하고,

상기 어드레스 핸들을 이용하여, 복수의 어드레스 맵 객체들로부터 네트워크 어드레스 맵 객체를 결정하는 단계를 더 포함하고, 상기 복수의 어드레스 맵 객체들은 상기 메모리에 저장되고, 상기 어드레스 맵 객체는 상기 결정된 전송 컨텍스트와 연관된다.

항목 27. 항목 26의 방법에 있어서,

상기 네트워크 어댑터 디바이스에 의해, 새로운 어드레스 핸들에 대한 요청을 수신하는 단계, 상기 요청은 상기 목적지 정보를 포함하고;

상기 새로운 목적지 정보를 이용하여, 상기 네트워크 어드레스 맵 객체를 식별하는 단계;

상기 새로운 어드레스 핸들을 생성하는 단계, 상기 새로운 어드레스 핸들은 상기 네트워크 어드레스 맵 객체와 연관되고; 및

상기 새로운 어드레스 핸들을 리턴하는 단계를 더 포함한다.

항목 28. 항목 26의 방법에 있어서,

상기 네트워크 어댑터 디바이스에 의해, 새로운 어드레스 핸들에 대한 요청을 수신하는 단계, 상기 요청은 새로운 목적지 정보를 포함하고;

상기 복수의 전송 컨텍스트들이 상기 새로운 목적지 정보와 관련된 전송 컨텍스트를 포함하지 않는다고 결정한 때:

새로운 전송 컨텍스트를 생성하는 단계; 및

상기 새로운 전송 컨텍스트에 상기 새로운 연결의 상태를 저장하는 단계; 및

상기 새로운 목적지 정보와 연관된 상기 네트워크 상에 새로운 목적지와 새로운 연결을 수립하는 단계;

새로운 네트워크 어드레스 맵 객체를 생성하는 단계, 상기 네트워크 어드레스 맵 객체는 상기 새로운 전송 컨텍스트와 연관되고;

상기 새로운 어드레스 핸들을 생성하는 단계, 상기 새로운 어드레스 핸들은 상기 새로운 네트워크 어드레스 맵 객체와 연관되고; 및

상기 새로운 어드레스 핸들을 리턴하는 단계를 더 포함한다.

항목 29. 컴퓨팅 시스템에 있어서,

호스트 디바이스를 포함하되, 상기 호스트 디바이스는:

프로세서; 및

상기 프로세서들에 결합되고 상기 프로세서에 의해 판독 가능한 메모리를 포함하되, 상기 메모리는 유저 애플리케이션들을 저장하도록 구성되고; 및

네트워크와 통신하도록 구성된 네트워크 어댑터 디바이스;를 포함하고,

상기 호스트 디바이스는 상기 유저 애플리케이션을 실행시키도록 구성되고, 상기 유저 애플리케이션은 :

상기 메모리에 복수의 버퍼들을 구성하도록 구성되고;

상기 네트워크 어댑터 디바이스는 :

상기 네트워크를 통하여 복수의 패킷들을 수신하고, 상기 복수의 패킷들은은 상기 네트워크상에 소스로부터 발원되고(originate) 상기 복수의 패킷들은 순서가 바뀌어서(out of order) 수신되고; 및

상기 복수의 패킷들로부터 패킷을 수신한 때:

상기 패킷의 소스 및 목적지와 관련된 전송 컨텍스트를 식별하고;

상기 패킷에 포함된 엔드 포인트 식별자를 이용하여, 상기 패킷이 상기 유저 애플리케이션에 대한 것인 것을 결정하고; 및

상기 수신된 패킷을 상기 복수의 버퍼들로부터 버퍼로 전송하고; 및

상기 식별된 전송 컨텍스트를 이용하여 상기 복수의 패킷들로부터 패킷들의 상태를 나타내는 응답을 상기 네트워크를 통하여 송신하도록 구성되고;

상기 유저 애플리케이션은 추가로:

상기 수신된 패킷들을 차례 차례로 배치하기 위해서 상기 복수의 버퍼들에서 수신된 상기 패킷들을 재순서화(re-order)하도록 구성된다.

항목 30. 항목 29의 컴퓨팅 시스템에 있어서, 상기 네트워크 어댑터 디바이스는 추가로:

상기 복수의 패킷들로부터 각각의 패킷에 포함된 식별자들을 모니터링하고; 및

상기 복수의 패킷들로부터 하나 이상의 패킷들이 수신되지 않았다고 결정하도록 구성되고;

상기 응답은 수신되지 않은 상기 하나 이상의 패킷을 식별한다.

항목 31. 항목 29 또는 30의 컴퓨팅 시스템에 있어서, 상기 네트워크 어댑터 디바이스는 추가로 :

상기 복수의 버퍼들이 풀(full)인 것을 결정하고; 및

상기 복수의 패킷들로부터 하나 이상의 패킷들을 드랍하도록 구성된다.

항목 32. 항목 31의 컴퓨팅 시스템에 있어서, 상기 응답은 드랍된 상기 하나 이상의 패킷들을 식별한다.

항목 33. 장치에 있어서,

프로세서; 및

복수의 수신 큐들;을 포함하고,

상기 장치는 :

네트워크 및 호스트 디바이스와 통신하고;

상기 네트워크를 통하여 패킷들을 수신하고, 상기 패킷들은은 상기 네트워크상에 소스로부터 발원되고(originate) 순서가 바뀌어서(out of order) 수신되는; 및

각각의 수신된 패킷에 대하여:

상기 수신된 패킷의 소스 및 목적지와 관련된 전송 컨텍스트를 식별하고;

상기 수신된 패킷이 다른 패킷들에 대하여 수신되는 순서를 식별하고;

상기 수신된 패킷이 수락될 수 있는지 여부를 결정하고; 및

상기 수신된 패킷이 수락될 수 있다고 결정한 때:

상기 수신된 패킷에 포함된 목적지 정보를 이용하여, 수신 큐를 결정하고, 상기 수신 큐는 상기 호스트 디바이스상에 유저 애플리케이션과 연관되고; 및

상기 수신된 패킷을 상기 수신 큐로 전송하도록 구성된다.

항목 34. 항목 33의 장치에 있어서, 상기 장치는 상기 패킷이 수락될 수 있다고 결정한 때, 상기 식별된 전송 컨텍스트를 이용하여, 하나 이상의 상기 수신된 패킷들의 상태를 나타내는 응답을 상기 네트워크를 통하여 송신하도록 더 구성된다.

항목 35. 항목 34의 장치에 있어서, 상기 응답은 상기 하나 이상의 패킷들이 수신되었다는 것을 표시한다.

항목 36. 항목 34의 장치에 있어서, 상기 응답은 상기 하나 이상의 패킷들이 수신되지 않았다는 것을 표시한다.

항목 37. 항목 33 내지 36 중 어느 하나의 장치에 있어서, 상기 장치는 제 2 수신 패킷에 대하여:

상기 제 2 수신 패킷이 수락될 수 없음을 결정하고; 및

상기 제 2 수신 패킷을 드랍하도록 구성된다.

항목 38. 항목 37의 장치에 있어서, 상기 장치는 상기 복수의 버퍼들이 풀(full)이라고 결정함으로써 상기 제 2 패킷이 수락될 수 없다고 결정하도록 구성된다.

항목 39. 항목 37의 장치에 있어서, 상기 장치는 상기 제 2 수신 패킷에 대응하는 데이터가 미리 수신되었다고 결정함으로써 상기 제 2 패킷이 수락될 수 없다고 결정하도록 구성된다.

항목 40. 항목 37의 장치에 있어서, 상기 장치는 상기 제 2 수신 패킷이 유효하지 않다(invalid)고 결정함으로써 상기 제 2 패킷이 수락될 수 없다고 결정하도록 구성된다.

항목 41. 항목 37의 장치에 있어서, 상기 장치는 상기 제 2 수신 패킷이 수락될 수 있다고 결정한 때, 상기 식별된 전송 컨텍스트를 이용하여, 재송신될 하나 이상의 패킷들을 식별하는 응답을 상기 네트워크를 통하여 송신하도록 더 구성되고, 상기 하나 이상의 패킷들은 상기 제 2 수신 패킷을 포함한다.

항목 42. 항목 33 내지 41 중 어느 하나의 장치에 있어서, 상기 식별된 전송 컨텍스트는 상기 장치와 상기 네트워크상의 상기 소스와의 연결 상태를 포함한다.

항목 43. 항목 33 내지 42 중 어느 하나의 장치에 있어서, 상기 식별된 전송 컨텍스트는 상기 네트워크 상의 상기 소스로부터 상기 장치로 상기 네트워크를 통하여 다수의 경로들을 제공한다.

항목 44. 항목 33 내지 43 중 어느 하나의 장치에 있어서, 상기 패킷들은 패킷들의 서브-플로우들로 분할된다.

항목 45. 항목 33 내지 44 중 어느 하나의 장치에 있어서, 각각의 패킷들의 서브-플로우는 상이한 네트워크 경로를 이용하여 수신된다.

항목 46. 항목 33 내지 44 중 어느 하나의 장치에 있어서, 상기 장치는 추가로 :

패킷들의 서브-플로우(sub-flow)에 대하여, 상기 패킷들의 서브-플로우로부터 각각의 패킷에 포함된 식별자들을 모니터링하고; 및

상기 식별자들을 이용하여, 상기 패킷들의 서브-플로우로부터 특정 패킷이 순서에 맞게(in order) 수신되었다고 결정하고;

상기 응답은 순서에 맞게 수신된 상기 패킷들의 서브-플로우로부터 하나 이상의 패킷들을 식별하고, 상기 패킷들의 서브-플로우로부터 상기 하나 이상의 패킷들은 상기 특정 패킷을 포함한다.

항목 47. 항목 33 내지 44 중 어느 하나의 장치에 있어서, 상기 장치는 추가로 :

패킷들의 서브-플로우(sub-flow)에 대하여, 상기 패킷들의 서브-플로우로부터 각각의 패킷에 포함된 식별자들을 모니터링하고; 및

상기 식별자들을 이용하여, 상기 패킷들의 서브-플로우로부터 특정 패킷이 수신되지 않았다고 결정하고;

상기 응답은 수신되지 않은 상기 패킷들의 서브-플로우로부터 하나 이상의 패킷들을 식별하고, 상기 패킷들의 서브-플로우로부터 상기 하나 이상의 패킷들은 상기 특정 패킷을 포함한다.

항목 48. 항목 33 내지 47 중 어느 하나의 장치에 있어서, 상기 장치는 네트워크 어댑터 디바이스이다.

항목 49. 항목 33 내지 48 중 어느 하나의 장치에 있어서, 상기 장치는 시스템-온-칩 (SoC), 필드-프로그램 가능한 게이트 어레이 (FPGA), 또는 애플리케이션-특정 집적 회로 (ASIC)이다.

항목 50. 방법에 있어서,

네트워크 어댑터 디바이스에서, 네트워크를 통하여 복수의 패킷들을 수신하는 단계, 상기 복수의 패킷들은은 상기 네트워크상에 소스로부터 발원되고(originate) 순서가 바뀌어서(out of order) 수신되고; 및

상기 복수의 패킷들로부터 패킷을 수신한 때:

상기 수신된 패킷의 소스 및 목적지와 관련된 전송 컨텍스트를 식별하는 단계;

상기 수신된 패킷이 상기 복수의 패킷들로부터의 다른 패킷들에 대하여 수신되는 순서를 식별하는 단계;

상기 수신된 패킷이 수락될 수 있는지 여부를 결정하는 단계; 및

상기 수신된 패킷이 수락될 수 있다고 결정한 때:

상기 수신된 패킷에 포함된 목적지 정보를 이용하여, 수신 큐를 결정하는 단계, 상기 수신 큐는 유저 애플리케이션과 연관되고; 및

상기 수신된 패킷을 상기 수신 큐로 전송하는 단계; 및

상기 식별된 전송 컨텍스트를 이용하여, 상기 복수의 패킷들로부터 하나 이상의 패킷들의 상태를 나타내는 응답을 상기 네트워크를 통하여 송신하는 단계를 포함한다.

항목 51. 항목 50의 방법에 있어서, 상기 응답은 상기 복수의 패킷들로부터 상기 하나 이상의 패킷들이 수신되었다는 것을 표시한다.

항목 52. 항목 50 또는 51의 방법에 있어서, 상기 응답은 상기 복수의 패킷들로부터 상기 하나 이상의 패킷들이 수신되지 않았다는 것을 표시한다.

항목 53. 항목 50 내지 52 중 어느 하나의 방법에 있어서, 제 2 수신 패킷에 대하여:

상기 제 2 수신 패킷이 수락될 수 있다고 결정하는 단계;

상기 제 2 수신 패킷을 드랍하는 단계;를 더 포함하고,

상기 응답은 재송신될 하나 이상의 패킷들을 식별하고, 상기 하나 이상의 패킷들은 상기 제 2 수신 패킷을 포함한다.

항목 54. 항목 50 내지 53 중 어느 하나의 방법에 있어서, 상기 식별된 전송 컨텍스트는 상기 네트워크 어댑터 디바이스와 상기 네트워크상의 상기 소스와의 연결 상태를 포함한다.

항목 55. 컴퓨팅 시스템에 있어서,

호스트 디바이스를 포함하되, 상기 호스트 디바이스는:

프로세서;

상기 프로세서들에 결합되고 상기 프로세서에 의해 판독 가능한 메모리를 포함하되, 상기 메모리는 유저 애플리케이션들을 저장하도록 구성되고; 및

네트워크와 통신하도록 구성된 네트워크 어댑터 디바이스;

상기 호스트 디바이스는 :

상기 유저 애플리케이션을 실행시키고, 상기 유저 애플리케이션은 상기 네트워크 어댑터 디바이스에 메시지들을 제공하도록 구성되고, 각각의 메시지는 어드레스 핸들을 포함하고;

상기 네트워크 어댑터 디바이스는 :

상기 유저 애플리케이션으로부터 각각의 메시지에 대하여:

상기 어드레스 핸들을 이용하여 상기 메시지에 대한 전송 컨텍스트를 결정하고, 상기 전송 컨텍스트는 상기 네트워크상의 목적지와 연관되고, 상기 전송 컨텍스트는 목적지 어드레스를 제공하고;

상기 메시지에 대한 패킷을 생성하고, 상기 패킷은 상기 목적지 어드레스를 포함하고; 및

상기 네트워크를 통하여 상기 패킷을 송신하고;

상기 네트워크를 통하여 응답들을 수신하고, 각각의 응답은 상기 메시지들에 대하여 발송된 상기 하나 이상의 패킷들의 상태를 나타내고; 및

상기 하나 이상의 패킷들의 상태를 상기 유저 애플리케이션으로 보고하도록 구성된다.

항목 56. 항목 55의 컴퓨팅 시스템에 있어서, 응답은 상기 하나 이상의 패킷들이 성공적으로 수신되었다는 것을 표시한다.

항목 57. 항목 55 또는 56의 컴퓨팅 시스템에 있어서, 응답은 상기 하나 이상의 패킷들이 수신되지 않았다는 것을 표시하고, 상기 네트워크 어댑터 디바이스는 추가로 :

수신되지 않았다고 표시된 상기 하나 이상의 패킷들을 재송신하도록 구성된다.

항목 58. 항목 55 내지 57중 어느 하나의 컴퓨팅 시스템에 있어서, 응답은 상기 하나 이상의 패킷들이 상기 목적지에서 드랍되었다는 것을 표시하고, 상기 네트워크 어댑터 디바이스는 추가로 :

상기 응답을 상기 유저 애플리케이션에 보고하도록 구성된다.

항목 59. 장치에 있어서,

프로세서; 및

복수의 발송 큐(send queue)들;

상기 장치는 호스트 디바이스 및 네트워크와 통신하도록 구성되고, 상기 장치는 추가로 :

상기 복수의 발송 큐들에서 상기 호스트 디바이스로부터 메시지들을 수신하고, 각각의 메시지는 개별 시퀀스 식별자를 포함하고, 상기 시퀀스 식별자는 상기 메시지의 소스로부터의 다른 메시지들에 대하여 각각의 개별 메시지의 시퀀스를 나타내고, 각각의 상기 메시지들은 동일한 목적지 정보와 연관되고;

프로세싱을 위해 상기 복수의 발송 큐들로부터 발송 큐를 결정하고 ; 및

상기 결정된 발송 큐내 각각의 메시지에 대하여:

상기 목적지 정보 및 상기 결정된 발송 큐의 아이덴티티(identity)를 이용하여 상기 네트워크상에 목적지와 관련된 전송 컨텍스트를 결정하고;

상기 전송 컨텍스트를 이용하여, 상기 메시지 및 상기 메시지의 시퀀스 식별자를 포함하는 패킷을 생성하고;

상기 전송 컨텍스트를 이용하여 상기 네트워크를 통하여 상기 패킷을 송신하고; 및

상기 송신된 패킷에 대한 상태를 모니터링하도록 구성된다.

항목 60. 항목 59의 장치에 있어서, 상기 장치는 추가로:

상기 네트워크를 통하여 응답을 수신하도록 구성되고, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상이 상기 네트워크 상의 상기 목적지에서 수신되었다는 것을 표시한다.

항목 61. 항목 60의 장치에 있어서, 상기 장치는 추가로:

상기 네트워크를 통하여 응답을 수신하고, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상이 상기 네트워크 상의 상기 목적지에서 수신되지 않았다는 것을 표시하고; 및

수신되지 않은 것으로 표시된 상기 하나 이상의 패킷들을 재송신하도록 구성된다.

항목 62. 항목 60의 장치에 있어서, 상기 장치는 추가로:

상기 네트워크를 통하여 응답을 수신하고, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상을 재송신하기 위한 요청을 포함하고; 및

상기 호스트 디바이스로 상기 응답을 보고(report)하도록 구성된다.

항목 63. 항목 59 내지 62 중 어느 하나의 장치에 있어서, 상기 전송 컨텍스트는 상기 네트워크 상의 상기 목적지로 상기 네트워크를 통하여 다수의 경로들을 제공한다.

항목 64. 항목 59 내지 63 중 어느 하나의 장치에 있어서, 상기 장치는 추가로 :

상기 메시지들에 대한 패킷들을 패킷들의 서브-플로우들로 분할하도록 구성된다.

항목 65. 항목 64의 장치에 있어서, 상기 장치는 추가로:

각각의 패킷들의 서브-플로우를 상이한 네트워크 경로를 이용하여 송신하도록 구성된다.

항목 66. 항목 64의 장치에 있어서, 상기 장치는 추가로:

패킷들의 서브-플로우로부터의 하나 이상의 패킷들이 성공적으로 수신되었다는 것을 나타내는 응답을 수신하도록 구성된다.

항목 67. 항목 64의 장치에 있어서, 상기 장치는 추가로:

패킷들의 서브-플로우로부터의 하나 이상의 패킷들이 상기 네트워크를 통하여 상기 목적지에서 수신되지 않았다는 것을 나타내는 응답을 수신하고;및

수신되지 않은 것으로 표시된 상기 하나 이상의 패킷들을 재송신하도록 구성된다.

항목 68. 항목 64의 장치에 있어서, 상기 장치는 각각의 패킷들의 서브-플로우에 대하여 추가로:

상기 패킷들의 서브-플로우로부터 패킷 송신시에, 타이머를 시작하고;

상기 타이머의 만료시에, 상기 패킷들의 서브-플로우로부터의 하나 이상의 패킷들을 재송신하도록 구성된다.

항목 69. 항목 59 내지 68 중 어느 하나의 장치에 있어서, 상기 장치는 네트워크 어댑터 디바이스이다.

항목 70. 항목 59 내지 69 중 어느 하나의 장치에 있어서, 상기 장치는 시스템-온-칩 (SoC), 필드-프로그램 가능한 게이트 어레이 (FPGA), 또는 애플리케이션-특정 집적 회로 (ASIC)이다.

항목 71. 방법에 있어서,

네트워크 어댑터 디바이스에 의해, 복수의 발송 큐들에서 상기 호스트 디바이스로부터 메시지들을 수신하는 단계, 각각의 메시지는 시퀀스 식별자를 포함하고, 상기 시퀀스 식별자는 상기 메시지의 소스로부터의 다른 메시지들에 대하여 각각의 개별 메시지의 시퀀스를 나타내고, 각각의 상기 메시지들은 동일한 목적지 정보와 연관되고;

프로세싱을 위해 상기 복수의 발송 큐들로부터 발송 큐를 결정하는 단계; 및

상기 결정된 발송 큐내 각각의 메시지에 대하여:

상기 목적지 정보 및 상기 결정된 발송 큐의 아이덴티티(identity)를 이용하여 전송 컨텍스트를 결정하는 단계, 상기 전송 컨텍스트는 상기 네트워크상의 목적지와 연관되고;

상기 전송 컨텍스트를 이용하여, 상기 메시지 및 상기 메시지의 시퀀스 식별자를 포함하는 패킷을 생성하는 단계;

상기 전송 컨텍스트를 이용하여 상기 네트워크를 통하여 상기 패킷을 송신하는 단계; 및

상기 송신된 패킷에 대한 상태를 모니터링하는 단계를 포함한다.

항목 72. 항목 71의 방법에 있어서,

상기 네트워크를 통하여 응답을 수신하는 단계를 더 포함하되, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상이 상기 네트워크 상의 상기 목적지에서 수신되었다는 것을 표시한다.

항목 73. 항목 71 또는 72의 방법에 있어서,

상기 네트워크를 통하여 응답을 수신하는 단계, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상이 상기 네트워크 상의 상기 목적지에서 수신되지 않았다는 것을 표시하고; 및

수신되지 않은 것으로 표시된 상기 하나 이상의 패킷들을 재송신하는 단계를 포함한다.

항목 74. 항목 71 내지 73 중 어느 하나의 방법에 있어서,

상기 네트워크를 통하여 응답을 수신하는 단계, 상기 응답은 상기 메시지들에 대한 상기 패킷들 중 하나 이상을 재송신하기 위한 요청을 포함하고; 및

상기 호스트 디바이스로 상기 응답을 보고(report)하는 단계를 더 포함한다.

항목 75. 항목 71 내지 74 중 어느 하나의 방법에 있어서, 패킷들의 서브-플로우에 대하여 :

상기 패킷을 송신 한 때, 타이머를 시작하는 단계;

상기 타이머의 만료시에, 상기 패킷들의 서브-플로우로부터의 하나 이상의 패킷들을 재송신하는 단계를 더 포함한다.

다양한 실시 예는, 또한, 어떤 경우에는 다수의 애플리케이션들 중 임의의 애플리케이션을 동작시키는 데 사용될 수 있는 하나 이상의 유저 컴퓨터, 컴퓨팅 디바이스 또는 처리 디바이스를 포함할 수 있는 다양한 운영 환경들에서 구현될 수 있다. 유저 또는 클라이언트 디바이스는, 모바일 소프트웨어를 실행하고 다수의 네트워킹 및 메시징 프로토콜들을 지원할 수 있는 셀룰러, 무선, 및 핸드헬드 디바이스들뿐만 아니라 표준 운영 체제를 실행하는 데스크톱 또는 랩톱 컴퓨터와 같은 다수의 범용 개인 컴퓨터들 중 임의의 것도 포함할 수 있다. 또한, 이러한 시스템은, 상업적으로 이용 가능한 다양한 운영 체제들 중 임의의 것을 실행하는 다수의 워크스테이션들, 및 개발 및 데이터베이스 관리와 같은 목적을 위한 다른 공지된 애플리케이션들을 포함할 수 있다. 이러한 디바이스들은, 또한, 네트워크를 통해 통신할 수 있는, 더미 단말, 씬 클라이언트, 게임 시스템, 및 기타 디바이스 등의 다른 전자 디바이스를 포함할 수 있다.

대부분의 실시 예들은, 전송 제어 프로토콜/인터넷 프로토콜("TCP/IP"), 개방 시스템 상호접속("OSI"), 파일 전송 프로토콜("FTP"), 범용 플러그 앤 플레이("UpnP"), 네트워크 파일 시스템(NFS), 공통 인터넷 파일 시스템("CIFS"), 및 AppleTalk 등의 상업적으로 이용가능한 다양한 프로토콜들 중 임의의 것을 사용하는 통신을 지원하도록 통상의 기술자에게 익숙한 적어도 하나의 네트워크를 이용한다. 네트워크는, 예를 들어, 로컬 에어리어 네트워크, 광역 네트워크, 가상 사설망, 인터넷, 인트라넷, 엑스트라넷, 공중 교환 전화망, 적외선 네트워크, 무선 네트워크, 및 이들의 임의의 조합일 수 있다.

웹 서버를 이용하는 실시 예들에서, 웹 서버는, "HTTP" 서버, FTP 서버, CGI(공통 게이트웨이 인터페이스) 서버, 데이터 서버, Java 서버, 및 비즈니스 애플리케이션 서버를 포함하는 다양한 서버 또는 미드티어 애플리케이션들 중 임의의 것을 실행할 수 있다. 서버(들)는, 또한, 예를 들어, Java^®, C, C# 혹은 C++, 또는 임의의 스크립팅 언어, 예컨대, Perl, Python 또는 TCL, 및 이들의 조합 등의 임의의 프로그래밍 언어로 기입된 하나 이상의 스크립트 또는 프로그램으로서 구현될 수도 있는 하나 이상의 웹 애플리케이션을 실행함으로써, 유저 디바이스로부터의 요청에 응답하여 프로그램 또는 스크립트를 실행할 수 있다. 서버(들)는, 또한, Oracle^®, Microsoft^®, Sybase^®, 및 IBM^®에 의해 상업적으로 이용 가능한 것을 포함하는 데이터베이스 서버를 포함할 수도 있지만, 이러한 예로 한정되지는 않는다.

환경은 상술한 바와 같이 다양한 데이터 저장소들 및 다른 메모리 및 저장 매체를 포함할 수 있다. 이들은, 네트워크에 걸쳐 컴퓨터들 중 임의의 컴퓨터 또는 모든 컴퓨터로부터 원격 또는 컴퓨터들 중 하나 이상에 대하여 로컬인(및/또는 그 하나 이상에 상주하는) 저장 매체 상과 같은 다양한 위치에 상주할 수 있다. 실시 예들의 특정 세트에 있어서, 정보는 통상의 기술자에게 익숙한 SAN(저장디바이스 영역 네트워크)에 상주할 수 있다. 유사하게, 컴퓨터, 서버, 또는 다른 네트워크 디바이스에 기인하는 기능들을 수행하기 위한 임의의 필요한 파일들은 적절하게 로컬 및/또는 원격으로 저장될 수 있다. 시스템이 컴퓨터화된 디바이스들을 포함하는 경우, 이러한 각 디바이스는 버스를 통해 전기적으로 결합될 수 있는 하드웨어 엘리먼트들을 포함할 수 있으며, 이 엘리먼트들은, 예를 들어, 적어도 하나의 CPU(중앙 처리 유닛), 적어도 하나의 입력 디바이스(예를 들어, 마우스, 키보드, 제어기, 터치 스크린, 또는 키패드), 및 적어도 하나의 출력 디바이스(예를 들어, 표시 디바이스, 프린터, 또는 스피커)를 포함할 수 있다. 또한, 이러한 시스템은, 디스크 드라이브, 광 스토리지, 및 랜덤 액세스 메모리("RAM") 또는 판독 전용 메모리("ROM") 등의 고체 상태 스토리지와 같은 하나 이상의 스토리지 및 탈착가능 미디어 디바이스, 메모리 카드, 플래시 카드 등을 포함할 수 있다.

이러한 디바이스는, 또한, 전술한 바와 같이, 컴퓨터 판독가능 저장매체 판독기, 통신 디바이스(예를 들어, 모뎀, 네트워크 카드(무선 또는 유선), 적외선 통신 디바이스 등), 및 작업 메모리를 포함할 수 있다. 컴퓨터 판독가능 저장매체 판독기는, 원격, 로컬, 고정식 및/또는 탈착식 스토리지를 나타내는 컴퓨터 판독가능 저장 매체 및 컴퓨터 판독가능 정보를 일시적으로 및/또는 더욱 영구적으로 포함, 저장, 송신, 및 검색하기 위한 저장 매체에 접속될 수 있거나 이러한 저장 매체들을 수용하도록 구성될 수 있다. 시스템 및 다양한 디바이스들은, 또한, 통상적으로, 클라이언트 애플리케이션 또는 웹 브라우저와 같은 운영 체제와 애플리케이션 프로그램을 포함하는 적어도 하나의 작업 메모리 디바이스 내에 위치하는 다수의 소프트웨어 애플리케이션, 모듈, 서비스 또는 다른 엘리먼트들을 포함한다. 다른 실시 예들은 상술한 바로부터 변형된 많은 예들을 가질 수도 있음을 이해해야 한다. 예를 들어, 맞춤형 하드웨어가 또한 사용될 수 있고/있거나, 특정 엘리먼트들이 하드웨어, (애플릿 등의 휴대용 소프트웨어를 포함하는) 소프트웨어, 또는 둘 모두로 구현될 수 있다. 또한, 네트워크 입력/출력 디바이스 등의 컴퓨팅 디바이스에 대한 접속을 채택할 수 있다.

코드 또는 코드의 일부를 포함하기 위한 저장 매체 컴퓨터 판독가능 매체는, RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD, 또는 기타 광학 저장소, 자기 카세트, 자기 테이프, 자기 디스크 저장소, 또는 기타 자기 스토리지, 또는 원하는 정보를 저장하는 데 사용될 수 있고 시스템 디바이스에 의해 액세스될 수 있는 다른 임의의 매체를 포함하는, 컴퓨터 판독가능 지시, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보의 저장 및/또는 송신을 위한 임의의 방법이나 기술로 구현되는 휘발성 및 비휘발성, 탈착가능 또는 비-탈착가능 매체 등의 저장 매체와 통신 매체를 포함하지만 이에 한정되지 않는, 당업계에 알려져 있거나 사용되는 임의의 적절한 매체를 포함할 수 있다. 본 명세서에서 제공된 교시와 개시 내용에 기초하여, 통상의 기술자는 다양한 실시 예를 구현하기 위한 다른 방식 및/또는 방법을 이해할 것이다.

이에 따라, 명세서 및 도면은 제한적인 의미라기보다는 예시적인 것으로 간주되어야 한다. 그러나, 특허청구범위에 기재된 본 개시 내용의 사상 및 범위를 벗어나지 않으면서 다양한 변경 및 수정이 이루어질 수도 있음은 명백할 것이다.

다른 변형도 본 개시 내용의 사상 내에 있다. 따라서, 개시된 기술들은 다양한 변형 및 대안적인 구조의 영향을 받기 쉽지만, 그 기술들의 예시된 실시 예들은 도면에 도시되어 있으며 위에서 상세히 설명하였다. 그러나, 본 개시 내용을 개시된 특정 형태 또는 형태들로 한정하려는 의도는 없지만, 반대로, 첨부된 청구범위에 정의된 바와 같이, 본 개시 내용의 사상 및 범위 내에 있는 모든 변형, 대안적인 구성, 및 등가물을 포함하려는 것임을 이해해야 한다.

(특히, 이하의 청구범위의 문맥에서) 개시된 실시 예들을 기술할 때 "한"(a), "하나"(an), "그"(the) 및 유사한 지시자의 사용은, 본 명세서에서 달리 명시되거나 문맥에 의해 명확하게 모순되지 않는 한, 단수 및 복수를 모두 포함하는 것으로 해석되어야 한다. "포함하는"(comprising), "갖는"(having), "포함하는"(including), 및 "포함하는"(containing)이라는 용어들은, 다른 언급되지 않는 한, 개방형 용어들(즉, "포함하지만 이에 한정되지 않는"을 의미)로서 해석되어야 한다. "연결된"이라는 용어는, 사이에 개재하는 것이 있더라도, 부분적으로 또는 전체적으로 포함되거나, 부착되거나, 함께 연결된 것으로서 해석되어야 한다. 본 명세서에서의 값들의 범위 열거는, 본 명세서에서 달리 지시되지 않는 한, 그 범위 내에 속하는 각각의 개별적인 값을 개별적으로 언급하는 약식 방법으로서 기능하기 위한 것일 뿐이며, 각각의 개별적인 값은 본 명세서에서 개별적으로 인용된 것처럼 본 명세서에 통합된다. 본 명세서에 기술된 모든 방법들은, 본 명세서에서 달리 지시되지 않는 한 또는 문맥에 의해 명백하게 모순되지 않는 한, 임의의 적합한 순서로 수행될 수 있다. 본 명세서에서 제공된 임의의 모든 예들 또는 예시적인 언어(예를 들어, "등의")를 사용하는 것은, 다르게 주장하지 않는 한, 본 개시 내용의 실시 예들을 더욱 잘 나타내기 위한 것이며, 본 개시 내용의 범위를 한정하지 않는다. 명세서에서의 어떠한 언어도, 청구되지 않은 엘리먼트를 본 개시 내용의 실시에 필수적인 것으로 나타내는 것으로서 해석되어서는 안 된다.

달리 특정하게 명시되지 않는 한, "X, Y, Z 중 적어도 하나"라는 문구와 같은 택일적인 언어는, 일반적으로 항목, 용어 등이 X, Y, 또는, Z, 또는 이들의 임의의 조합(예를 들어, X, Y 및/또는 Z)일 수 있다는 점을 나타내도록 사용되는 문맥으로 이해된다. 따라서, 이러한 택일적인 언어는, 일반적으로, 어떤 실시 예들이 X 중 적어도 하나, Y 중 적어도 하나, 또는 Z 중 적어도 하나가 각각에 대하여 존재해야 한다는 점을 암시하려는 것이 아니며 그러한 암시로 되어서도 안 된다.

본 개시 내용을 수행하기 위해 본 발명자들에게 공지된 최상의 모드를 포함하여 본 개시 내용의 바람직한 실시 예들이 본 명세서에 기술된다. 이들 바람직한 실시 예들의 변형은 전술한 설명을 읽음으로써 통상의 기술자에게 명백해질 수 있다. 본 발명자는 통상의 기술자가 그러한 변형을 적절하게 사용하고, 본 발명자는 본 개시 내용을 본 명세서에 구체적으로 기술된 것 이외의 방법으로 실시하고자 한다. 이에 따라, 본 개시 내용은 적용 가능한 법률에 의해 허용되는 바와 같이 본 명세서에 첨부된 청구범위에 기재된 청구 대상의 모든 변경 및 등가물을 포함한다. 또한, 본 명세서에서 달리 지시되지 않는 한 또는 문맥에 의해 명확하게 모순되지 않는 한, 모든 가능한 변형에서 상기 언급된 엘리먼트들의 임의의 조합이 본 개시 내용에 포함된다.

Claims (28)

1. 호스트 디바이스
   - 상기 호스트 디바이스는,
   프로세서;
   상기 프로세서와 결합되고, 상기 프로세서에 의해 판독 가능한 메모리를 포함하며, 상기 메모리는 유저 애플리케이션을 저장하도록 구성됨 -; 및
   네트워크와 통신하도록 구성되는 네트워크 어댑터 디바이스를 포함하고,
   상기 호스트 디바이스는 상기 유저 애플리케이션을 실행하도록 구성되고, 상기 유저 애플리케이션의 실행은 상기 프로세서로 하여금,
   데이터 세트에 대한 목적지 주소를 결정하고 - 상기 목적지 주소는 상기 네트워크 상의 서버를 식별함 -;
   상기 목적지 주소에 대한 어드레스 핸들을 결정하고 - 상기 어드레스 핸들은 상기 네트워크 어댑터 디바이스의 메모리를 판독하기 위한 인덱스이고, 상기 네트워크 어댑터 디바이스의 메모리는 복수의 전송 컨텍스트를 저장하도록 동작 가능함-;
   상기 데이터 세트와 상기 어드레스 핸들을 상기 네트워크 어댑터 디바이스에 제공하도록 하며;
   상기 네트워크 어댑터 디바이스는,
   상기 어드레스 핸들을 사용하여, 상기 네트워크 어댑터 디바이스의 메모리에 유지되는 상기 복수의 전송 컨텍스트로부터 전송 컨텍스트를 식별하고 - 전송 서비스는 상기 전송 컨텍스트에 할당되고, 상기 전송 서비스는 상기 목적지 주소에 의해 식별된 상기 서버에 패킷을 전송하기 위한 프로토콜을 제공하고, 상기 전송 컨텍스트는 상기 목적지 주소에 의해 식별된 상기 서버에 전송된 패킷의 상태를 유지함 -,
   패킷을 생성하고 - 상기 패킷은 상기 데이터 세트의 적어도 일부를 포함하고, 상기 전송 컨텍스트는 상기 패킷을 생성하기 위한 데이터를 제공하고, 상기 패킷은 상기 목적지 주소로 어드레스 됨 -; 그리고
   상기 네트워크를 통해 상기 패킷을 전송하도록 구성되는 컴퓨팅 시스템.
2. 청구항 1에 있어서,
   상기 호스트 디바이스는 드라이버 프로그램을 실행하도록 추가로 구성되고, 상기 유저 애플리케이션의 실행은 상기 프로세서가 상기 목적지 주소에 대한 상기 어드레스 핸들을 결정할 수 없을 때, 상기 드라이버 프로그램으로부터 상기 어드레스 핸들을 요청하도록 하고 - 상기 요청은 상기 목적지 주소를 포함함 -;
   상기 드라이버 프로그램의 실행은 상기 프로세서로 하여금,
   어드레스 맵을 사용하여 상기 목적지 주소에 대한 상기 어드레스 핸들을 결정하고, 그리고
   상기 유저 애플리케이션에 상기 어드레스 핸들을 제공하도록 하는 컴퓨팅 시스템.
3. 청구항 2에 있어서,
   상기 드라이버 프로그램의 실행은 또한 상기 프로세서로 하여금,
   상기 어드레스 맵이 상기 목적지 주소를 포함하지 않는 것으로 결정하고; 그리고
   상기 네트워크 어댑터 디바이스에 상기 목적지 주소를 제공하며;
   상기 네트워크 어댑터 디바이스는 추가로,
   새로운 통신 채널에 대한 상기 전송 컨텍스트를 생성하고 - 상기 전송 컨텍스트를 생성하는 것은 상기 목적지 주소를 상기 전송 컨텍스트에 할당하는 것을 포함함 -;
   상기 어드레스 핸들을 사용하여, 상기 네트워크 어댑터 디바이스의 메모리에 상기 전송 컨텍스트를 저장하고;
   상기 드라이버 프로그램에 상기 어드레스 핸들을 제공하고; 그리고
   상기 목적지 주소에 의해 식별된 상기 서버와 상기 새로운 통신 채널을 확립하고;
   상기 드라이버 프로그램은 또한,
   상기 어드레스 핸들을 사용하여, 상기 어드레스 맵에 상기 목적지 주소를 저장하도록 구성되는 컴퓨팅 시스템.
4. 장치로서,
   프로세서; 및
   상기 프로세서와 결합되고, 상기 프로세서에 의해 판독 가능한 메모리를 포함하고, 상기 메모리는 복수의 전송 컨텍스트를 저장하도록 구성되고;
   상기 장치는,
   데이터 세트와 상기 데이터 세트에 대한 네트워크 상의 목적지를 식별하는 목적지 정보를 수신하고; 그리고
   상기 목적지 정보를 사용하여, 상기 복수의 전송 컨텍스트로부터 전송 컨텍스트를 결정하고 - 전송 서비스는 상기 전송 컨텍스트에 할당되고, 상기 전송 서비스는 상기 장치와 상기 네트워크 상의 목적지 사이에서 패킷을 전송하기 위한 프로토콜을 제공하고, 그리고 상기 전송 컨텍스트는 상기 네트워크 상의 목적지에 전송된 패킷의 상태를 유지함 -; 그리고
   상기 네트워크 상의 목적지에 상기 데이터 세트를 전송하기 위해 상기 전송 서비스를 사용하도록 구성되는 장치.
5. 청구항 4에 있어서,
   상기 장치는,
   상기 데이터 세트의 적어도 일부를 포함하는 패킷을 생성하고; 그리고
   상기 네트워크를 통해 상기 패킷을 전송하도록 - 상기 패킷은 상기 전송 서비스에 의해 제공되는 상기 프로토콜에 따라 전송됨 - 구성되는 장치.
6. 청구항 4에 있어서,
   상기 목적지 정보는 어드레스 핸들을 포함하고, 상기 장치는 또한,
   상기 어드레스 핸들을 사용하여, 상기 메모리에 저장된 복수의 어드레스 맵 객체로부터 네트워크 어드레스 맵 객체를 결정하도록 - 상기 어드레스 맵 객체는 상기 메모리에 전송 컨텍스트에 대한 정보를 저장하기 위한 데이터 구조를 제공함 - 구성되는 장치.
7. 청구항 6에 있어서,
   상기 네트워크 어드레스 맵 객체는 미리 생성된 패킷 헤더를 포함하는 장치.
8. 청구항 6에 있어서,
   상기 장치는 또한,
   새로운 어드레스 핸들에 대한 요청을 수신하고 - 상기 요청은 상기 목적지 정보를 포함함 -;
   상기 목적지 정보를 사용하여, 상기 네트워크 어드레스 맵 객체를 식별하고;
   상기 새로운 어드레스 핸들을 생성하고 - 상기 새로운 어드레스 핸들은 상기 네트워크 어드레스 맵 객체를 저장하기 위한 메모리의 인덱스임 -; 그리고
   상기 새로운 어드레스 핸들을 리턴하도록 구성되는 장치.
9. 청구항 6에 있어서,
   상기 장치는 또한,
   새로운 어드레스 핸들에 대한 요청을 수신하고 - 상기 요청은 새로운 목적지 정보를 포함함 -;
   상기 복수의 전송 컨텍스트가 상기 새로운 목적지 정보에 대한 전송 컨텍스트를 포함하지 않는 것으로 결정되면,
   새로운 통신 채널에 대한 새로운 전송 컨텍스트를 생성하고;
   새로운 네트워크 어드레스 맵 객체를 생성하고 - 상기 네트워크 어드레스 맵 객체는 상기 메모리에 상기 새로운 전송 컨텍스트에 대한 정보를 저장하기 위한 데이터 구조임 -;
   상기 새로운 어드레스 핸들을 생성하고 - 상기 새로운 어드레스 핸들은 상기 메모리에 상기 새로운 네트워크 어드레스 맵 객체를 저장하기 위한 인덱스임 -; 그리고
   상기 새로운 어드레스 핸들을 리턴하도록 구성되는 장치.
10. 청구항 9에 있어서,
    상기 장치는 또한, 상기 복수의 전송 컨텍스트가 상기 새로운 목적지 정보에 대한 전송 컨텍스트를 포함하지 않는 것으로 결정되면, 상기 새로운 목적지 정보에 의해 식별되는 상기 네트워크 상의 새로운 목적지와의 새로운 통신 채널을 확립하도록 구성되는 장치.
11. 청구항 9에 있어서,
    새로운 네트워크 어드레스 맵 객체를 생성하는 것은 상기 새로운 목적지 정보를 사용하는 패킷 헤더를 생성하는 것을 포함하고, 상기 패킷 헤더는 상기 새로운 네트워크 어드레스 맵 객체의 일부로서 저장되는 장치.
12. 청구항 4에 있어서,
    상기 장치는 상기 목적지 정보에 의해 식별되는 상기 네트워크 상의 목적지와의 통신 채널을 확립하도록 추가로 구성되는 장치.
13. 청구항 4에 있어서,
    상기 목적지 정보는 네트워크 어드레스를 포함하는 장치.
14. 청구항 4에 있어서,
    상기 목적지 정보는 플로우 식별자를 포함하는 장치.
15. 청구항 4에 있어서,
    상기 네트워크 상의 목적지는 상기 네트워크 상의 서버인 장치.
16. 청구항 4에 있어서,
    상기 네트워크 상의 목적지는 하나 이상의 인터넷 프로토콜(Internet Protocol) 어드레스와 연관되는 장치.
17. 청구항 4에 있어서,
    상기 네트워크 상의 목적지는 인터넷 프로토콜 어드레스와 통신 엔드 포인트 식별자와 연관되는 장치.
18. 청구항 4에 있어서,
    상기 데이터 세트는 시퀀스 식별자를 포함하고 - 상기 시퀀스 식별자는 동일한 애플리케이션으로부터의 다른 데이터 세트에 대한 데이터 세트의 시퀀스를 나타냄-, 상기 장치는 또한,
    상기 데이터 세트의 적어도 일부와 상기 시퀀스 식별자를 포함하는 패킷을 생성하고;
    상기 네트워크를 통해 상기 패킷을 전송하고 - 상기 패킷은 상기 전송 서비스에 의해 제공되는 상기 프로토콜에 따라 전송됨 -; 그리고
    상기 패킷에 대한 상태를 모니터링하도록 구성되는 장치.
19. 청구항 4에 있어서,
    상기 장치는 네트워크 어댑터 디바이스인 장치.
20. 청구항 4에 있어서,
    상기 장치는 시스템-온-칩 (system-on-a-chip, SoC), 필드-프로그램 가능한 게이트 어레이 (field-programmable gate array, FPGA), 또는 애플리케이션-특정 집적 회로 (application-specific integrated circuit, ASIC)를 포함하는 장치.
21. 청구항 4에 있어서,
    상기 전송 서비스에 대한 동작을 수행하도록 구성되는 집적 회로를 더 포함하는 장치.
22. 청구항 21에 있어서,
    상기 동작은 상기 데이터 세트를 상기 네트워크 상의 목적지로 전송하는 것을 포함하는 장치.
23. 청구항 21에 있어서,
    상기 집적 회로는 상기 동작을 수행하기 위한 펌웨어를 실행하는 장치.
24. 네트워크 어댑터 디바이스에 의해 데이터 세트와 상기 데이터 세트에 대한 네트워크 상의 목적지를 식별하는 목적지 정보를 수신하는 단계;
    상기 목적지 정보를 사용하여, 복수의 전송 컨텍스트로부터 전송 컨텍스트를 결정하는 단계 - 전송 서비스는 상기 전송 컨텍스트에 할당되고, 상기 전송 서비스는 상기 네트워크를 통해 상기 네트워크 상의 목적지에 패킷을 전송하기 위한 프로토콜을 제공하고, 상기 전송 컨텍스트는 상기 네트워크 상의 목적지에 전송된 패킷의 상태를 유지함 -; 및
    상기 전송 서비스를 사용하여 상기 네트워크 상의 목적지에 상기 데이터 세트를 전송하는 단계를 포함하는 방법.
25. 청구항 24에 있어서,
    상기 데이터 세트의 적어도 일부를 포함하는 패킷을 생성하는 단계; 및
    상기 네트워크를 통해 패킷을 전송하는 단계를 포함하고, 상기 패킷은 상기 전송 서비스에 의해 제공된 상기 프로토콜에 따라 전송되는 방법.
26. 청구항 24에 있어서,
    상기 목적지 정보는 어드레스 핸들을 포함하고, 또한,
    상기 어드레스 핸들을 사용하여, 상기 네트워크 어댑터 디바이스의 메모리에 저장된 복수의 어드레스 맵 객체로부터 네트워크 어드레스 맵 객체를 결정하는 단계를 더 포함하고, 상기 어드레스 맵 객체는 상기 메모리에 상기 전송 컨텍스트에 대한 정보를 저장하기 위한 데이터 구조를 제공하는 방법.
27. 청구항 26에 있어서,
    상기 네트워크 어댑터 디바이스에 의해 새로운 어드레스 핸들에 대한 요청을 수신하는 단계 - 상기 요청은 상기 목적지 정보를 포함함 -;
    상기 목적지 정보를 사용하여, 상기 네트워크 어드레스 맵 객체를 식별하는 단계;
    상기 새로운 어드레스 핸들을 생성하는 단계 - 상기 새로운 어드레스 핸들은 상기 네트워크 어드레스 맵 객체와 연관됨 -; 및
    상기 새로운 어드레스 핸들을 리턴하는 단계를 더 포함하는 방법.
28. 청구항 26에 있어서,
    상기 네트워크 어댑터 디바이스에 의해, 새로운 어드레스 핸들에 대한 요청을 수신하는 단계 - 상기 요청은 새로운 목적지 정보를 포함함 -;
    상기 복수의 전송 컨텍스트가 상기 새로운 목적지 정보와 연관된 전송 컨텍스트를 포함하지 않는 것으로 결정되면,
    새로운 통신 채널에 대하여, 새로운 전송 컨텍스트를 생성하는 단계;
    상기 새로운 목적지 정보와 연관된 상기 네트워크 상의 새로운 목적지와의 상기 새로운 통신 채널을 확립하는 단계;
    새로운 네트워크 어드레스 맵 객체를 생성하는 단계 - 상기 네트워크 어드레스 맵 객체는 상기 새로운 전송 컨텍스트와 연관됨 -;
    상기 새로운 어드레스 핸들을 생성하는 단계 - 상기 새로운 어드레스 핸들은 상기 새로운 네트워크 어드레스 맵 객체와 연관됨 -; 및
    상기 새로운 어드레스 핸들을 리턴하는 단계를 더 포함하는 방법.

Images