일반적으로 UDP는 비연결 지향형 프로토콜로 알려져 있다. 맞는 말이다. 하지만 디폴트 UDP에 connect라는 것을 첨가하여 보다 편리 하게 쓸 수 있는 것도 사실이다.
UDP소켓에다 connect 함수를 사용 한다는 것은 TCP의 그것 처럼 동작한다는 뜻은 아니다(Three-way handshaing 이라던지 하는 과정 들이 없다). 다만 커널에 소켓이 향하고 있는 주소를 기록해 두고 send 할 때 마다 주소를 넘겨 줘야 한다는 것 외의 모든 동작방법이나 기타등등은 다 똑같다.
자꾸 말을 번복하는 것 같지만, 내부에서 돌아가는 것은 다 똑같으나 사용법에 있어서 connected UDP와 unconnected(default) UDP는 다소 다른 점이 있다.
- 더 이상 목적지 주소와 포트를 지정 할 필요가 없다.
일반적으로 sendto 대신에 write를 사용하고, 꼭 sendto를 사용하고 싶다면, 목적지 주소(다섯번째 파라메터)는 NULL을 지정해야 하며, 주소 구조체의 크기(여섯 번째 파라메터)는 0이 되어야만 한다. - 데이터그램을 받기 위해 recvfrom을 사용 할 필요가 없다.
read, recv, recvmsg를 대신 사용하게 된다. connect로 목적지 주소를 지정한 소켓은, 그 주소에서 온 데이터그램만을 받아 들이고 다른 주소지의 데이터그램들은 무시하게 되므로, 주소를 알아내야 할 필요가 없다. - Asyncronous Error가 프로세스에게 리턴된다.
예를들어 상대에게 UDP메시지를 보냈지만 목적 호스트에 메시지를 수신하는 프로세스가 없다고 가정하자. 상대측의 UDP는 ICMP unreachable 메시지를 다시 이쪽으로 반환 하겠지만 커널은 어떤 소켓에 그 메시지를 되돌려 줘야 할지 모른다. ICMP메시지가 UDP의 헤더의 사본을 가지고는 있지만, 스택은 어떤 어플리케이션이 그 데이터그램을 보냈는지에 대한 정보가 없다. 하지만 소켓을 상대측의 주소와 연결한다면 이 사실은 소켓과 관련 된 PCB에 기록될 것이고, UDP헤더의 사본을 PCB에 매치시켜 어떤 소켓이 ICMP메시지를 전달하는지 알 수 있게 된다. - BSD의 경우에는 약 1/3 정도의 성능 향상을 기대 할 수 있다.
BSD에서 sendto는 특수한 경우로, sendto를 이용해 데이터가 전송 될 때, 커널은 소켓을 임시로 연결하고, 데이터그램을 전송하고, 그 후 소켓에 대한 연결을 끊는다.
아래는 unconnected(default) UDP의 sendto 과정을 나타낸다.
1. Connect the socket
2. Output the first datagram
3. Unconnect the socket
4. Connect the socket
5. Output the second datagram
6. Unconnect the socket
목적지로 두개의 데이터그램을 날려 보냈고, 하나의 데이터그램을 날릴때 마다 connect/unconnect과정을 거치고 있다. 하지만 어플리케이션이 여러개의 데이터그램이 한 peer로만 전송된다고 가정하고 connected UDP를 사용하게 되면 아래와 같은 과정으로 줄어 든다.
1. Connect the socket
2. Output the first datagram
3. Output the second datagram
4.3BSD와 이와 유사한 SunOS 4.1.1에 대한 연구 결과 [Partridge and Pink 1993]에서는 이런 방법으로 연결을 설정하고 종료하는 것이 UDP 데이터그램 전송에 걸리는 시간의 1/3을 차지 한다고 한다. 이러한 UDP 코드는 4.4BSD와 그 다음 버젼인 FreeBSD 등에서도 사실상 변하지 않고 남아 있다. 특히 이 스택들은 여전히 임시 연결과 임시 종료를 구현하고 있다. 따라서 연속되는 UDP데이터그램을 같은 상대측에 보내려고 한다면 먼저 connect를 사용해서 효율의 향상을 기대 할 수 있다.
부록 1. 같이 읽으면 좋은 글
- UNIX Network Programming
- Effective TCP/IP
- http://coolengineer.com/214
