Middleware Protocol과 Communication

Types of Communication

우리가 지금까지 생각했었던 컴퓨터 통신은 메세지를 보내고 받는 것이다. TCP나 UDP를 가지고 소켓 프로그래밍을 해봤으면 이런 방식을 사용해 봤을 것이다. 커뮤니케이션 타입을 보면 애플리케이션 레이어 입장에서 메세지를 주고 받는 방식이 단순히 tcp, udp를 사용하는 방식만 있는게 아니다. 우리가 매일 사용하고 있는 애플리케이션의 커뮤니케이션 방식은 사실은 다 다르다. 세부적으로 따져보면 커뮤니케이션 타입을 나눌 수 있고 기준에 따라 다음과 같이 나눌 수 있다.

• Persistent vs. transient communication
• Synchronous vs. asynchronous communication
• Discrete vs. streaming communication

이렇게 커뮤니케이션 타입의 특징에 따라 다양하고 적절하게 통신 서비스를 제공해 줄 수 있으면 좋을 것이다.

본론으로 들어가기 전에 예를 들어 중간에 이메일 서비스 하나가 갑자기 튀어 나왔다고 가정해보자. 우리가 매일 사용하는 이메일 시스템도 어떻게 보면 애플리케이션이 사용하는 미들웨어 레이어 서비스의 일종이라고 생각을 해 볼 수도 있다.

이메일 서비스를 제공해주기 위해 메일 서버가 존재한다. 메일 서버는 보내는 쪽과 받는 쪽 둘다에 존재하며 메일 서버 사이에 이메일 관련된 프로토콜을 이용을 해서 누군가 보낸 이메일 메시지를 받는 사람 쪽 애플리케이션에게 전달을 해준다. 이런 이메일 시스템이 미들웨어 레이어 서비스의 역할이라고 생각해 볼 수도 있다.

Transient Communication

TCP나 UDP에서 처럼 보내는 프로세스와 받는 프로세스 모두 준비가 되어 있어야 하는 방식이다. TCP 같은 경우 상대방이 실행중이지 않으면 커넥션 조차 맺을 수 없다. UDP도 보낼 순 있지만 보내는 순간 대상 프로세스가 실행중이지 않다면 못받는다. 지금 못받는 것은 나중에도 받을 수 없다. 이는 전달되는 메세지가 중간에 저장되는 곳이 없다는 의미이다. 이 부분에서부터 TCP, UDP 만으로는 부족하다는 것이다.

Persistent Communication

메세지를 중간에 저장해 주어 메시지를 받는 프로세스가 현재 온라인 상태가 아니라면 저장해 놨다가 받는 쪽이 온라인 상태가 됐을 때 전달을 해 주는 것이다. TCP, UDP의 한계로 인해 생겨났다. 메세지를 서버가 있다면 서버가 저장을 해 주고 미들웨어의 역할을 하는 시스템이 있다면 미들웨어 단에서 저장을 해 주면 되는 것이다. 대표적인 예로 이메일 서비스가 있다.

Asynchronous Communication

Sender가 메세지를 보내고 난 다음에 바로 실행을 계속 하는 것이다. 메세지를 보내고 상대방이 응답하는 것을 기다리지 않고 그 다음 task를 바로 진행하는 것이다.

Synchronous Communication

클라이언트가 서버로 요청 메시지를 보내고 서버가 요청에 대한 응답을 보내 줄 때까지 기다리는 것이다. 응답을 받은 후에 그 다음 작업을 수행한다. Synchronous 커뮤니케이션의 경우 Sender 쪽 애플리케이션은 메시지를 보내고 난 다음에 응답이 올 때까지 blocked 된다.

Synchronous Communication의 경우 누가 응답하는지에 따라 크게 세 가지로 구분할 수 있다. 그림에서 윗 쪽 x축은 Client이고 아랫쪽 x축은 Server이다. Client 자체적으로 로컬 프로세싱을 하다 미들웨어 서비스를 이용하여 화살표에 표시된 것 처럼 서버에게 메시지를 보낸다. 메세지를 synchronous하게 보냈기 때문에 클라이언트는 보내고 난 다음 후 기다린다. 서버가 메시지를 받은 요청사항을 처리 해서 결과 응답 메시지를 만들어서 클라이언트한테 다시 보낸다. 그 기간동안 클라이언트는 대기하고 있다가 서버가 보내는 응답 메세지를 받고 난 후 그 다음 작업을 수행한다.

세 가지 동기화 포인트

클라이언트 서비스를 언제까지 block 시킬지에 대한 세 가지 동기화 포인트가 있다. 중간에서 미들웨어가 응답해 주는 것이다. 클라이언트의 미들웨어가 응답해 주는 경우 잘 보내줄 것이다는 의미이다. 이 시점에서 클라이언트는 자신의 미들웨어가 잘 받았다는 것을 알 수 있다. 그 다음은 수신 측 미들웨어가 응답해 주는 것이다. 이는 잘 받았고 서버 애플리케이션에 전달해주겠다는 의미이다. 이 시점에서는 상대측 미들웨어가 잘 받았다는 것을 알 수 있다. 마지막으로 서버가 잘 받고 다 처리한 후에 응답을 주었다는 것을 알 수 있다.

두 타입의 조합

실제 우리가 사용하는 커뮤니케이션을 보면 두 가지 부분을 조합해서 사용하고 있다. 메세지 큐잉 시스템의 예로 이메일 시스템을 예로 생각해보자. 이메일 시스템의 경우 persistent하고 Asynchronous 하다. 앞에서 개념을 얘기했더니 RPC 리모트 프로시저 콜은 transient하고 synchronous 해야 한다. 이는 한 예일 뿐이고 다양한 조합으로 생각을 해 볼 수 있다.

• 애플리케인션 통신

통신 방식과 종류는 다양하지만 통신이라 했을 때 애플리케이션 통신을 생각을 하면 된다. 이메일 서비스를 생각해보면 클라이언트 입장에서는 사용자가 작성한 이메일을 전송한 후 보낸 이메일에 대한 응답을 기다리지 않는다. 그런 의미에서는 이메일 애플리케이션을 사용하는 통신은 비동기적인 통신으로 보는게 맞다. 그렇지만 한 레벨 아래에서 생각해보면 Transport layer의 TCP 경우 가장 중요한 특징은 신뢰적인 전송이다. TCP 레벨에서 메시지 전달을 본다면 동기적이라 볼 수 있다. 완전한 synchronous라 보기는 힘들지만 상대방이 제대로 받았는지를 확인한다는 측면에서는 synchronous 통신을 사용한다고 볼 수 있다. 하지만 우리는 Transport layer의 동작을 따지지말고 애플리케이션 레벨에서만 생각한다.