RSocket

Motivation

크고 분산된 환경에서는 많은 팀들이 서로 다른 기술, 언어를 가지고 모듈화 시스템에서 개발 합니다. 여기서 각 모듈간에 빠르고 안정적으로 또한 효율적이고 Scalable 하게 소통할 수 있는 수단이 필요합니다.

Rsocket의 네트워크 communication은 비동기적으로 이뤄집니다. Rsocket은 이러한 방식을 단일 커넥션의 메세지를 multiplexed streams로 처리합니다. 또한 절대 응답을 받기를 기다리지(Blocking)하지 않습니다.

이러한 방식을 사용하는 이유는 HTTP/2가 message-oriented protocol을 사용하는 것으로 설명할 수 있습니다. 자세한 사항은 Http/2 Article을 확인해 봅시다.

대표적으로 HTTP/1.1은 piplining을 통해 해결하고자 하였지만 완벽히 문제를 해결하지는 못했다.(크고 느린 response는 아직 뒤에 있는 요청을 Blocking하고 있다.) 추가적으로 pipelining은 배포하기가 매우 힘들었는데 많은 서버와 중간 매체들이 적절하게 process하지 못했기 때문이다.

Terminology

• Frame: 요청, 응답 또는 프로토콜 처리를 포함하는 단일 메시지입니다.
• Fragment: Frame에 포함하기 위해 분할된 Application 메시지의 일부입니다.
  • 조각화 및 재조립이 수행됩니다.
• Transport: RSocket 프로토콜을 전달하는 데 사용되는 프로토콜입니다.
  • WebSockets, TCP 또는Aeron 중 하나입니다
• Stream: 작업(request/response) 단위입니다.
• Request: Stream Request, 4 가지 유형 중 하나 일 수 있습니다. 뿐만 아니라 더 많은 항목을 요청하거나 이전 요청을 취소합니다.
• Payload: 이전 요청에서 만든 스트림과 연결된 데이터를 포함합니다.
  • 반응형 스트림및 Rx에서 이것은 'onNext' 이벤트입니다.
• Complete: 성공적인 완료를 알리기 위해 Stream에서 전송된 이벤트입니다.
  • 반응형 스트림 및 Rx에서 이것은 'onComplete' 이벤트입니다.
• Client: 연결을 시작하는 쪽입니다.
• Server: 클라이언트의 연결을 수락하는 쪽입니다.
• Connection: 클라이언트와 서버 간의 전송 세션 인스턴스입니다.
• Requester: 요청을 보내는 쪽입니다. 연결에는 각 방향으로 1개씩 최대 2명의 요청자가 있습니다.
• Responder: 요청을 받는 쪽입니다. 연결에는 각 방향으로 1개씩 최대 2개의 응답자가 있습니다.

Interaction Model

Fire-and-Forget

response로 아무것도 받지 않을 때 유용한 방법
Client가 요청을 보내고 응답을 기다리지 않는다.

Request / Response (single-reponse)

• 실직적 구현은 HTTP와 유사합니다.(요청에 대해 응답을 받음)
• 물론 비동기적으로 메세지가 전송된다.

Request / Stream (multi-response, finite)

• Collection, List를 응답으로 받지만 완성된 객체를 받는 것이 아니라 single response로 여러 개의 item이 담긴 Stream을 받습니다.
• 예를 들자면
  • list of videos
  • products in a catalog
  • file line-by-line

Channel

• Channel은 양방향 통신입니다. (즉 양방향 Stream을 사용합니다.)
  • 만약 양방향이 아니었더라면 Client는 처음 Request를 취소하고 다시 요청하고 모든 데이터를 받아야 합니다.
  • subscription을 새로 업데이트하고 차이를 얻는 대신 이러한 작업을 해야 한다는 것

Http/2

http/2는 http/1.x보다 훨씬 좋은 성능을 보이지만 결국 request, response의 모델을 벗어나지 못합니다. 또한 Application에서 Flow를 control하는 것도 불가능해 보입니다.