흠..

ECC 에 대한 강좌를 올리려고 했는데
몇가지 제가 잘못 알고 있던 것이 발견되어서
제가 퍼펙트하게 이해할때까지 잠시 미루고요...
이해되면 바로 올리겠습니다.

이해해 주세요.. ㅜㅜ

대신에 UDS 에 대한 몇 가지 실험에 대한 내용을 정리해 올릴께요

저는 주로 임베디드 프로그램을 작성할때
프로세스를 여러게 나누어서 작성하는데요
이때 프로세스간의 통신을 UDS 를 사용합니다.

그런데 이것을 사용하다가 보니 제가 잘못알고 있는 특성이 있다는 생각이 들었습니다.
그래서 의문나는 점이 있어서 이를 실험한 결과에 대한 문서 입니다.

UDS 특성 실험

           1. 개요

이 문서는 이전 부터 사용하던 UDS IPC 통신에 대하여 실제 사용에서 일어날수 있는 몇가지 상황에 대하여 사전에 실험하고 UDS IPC 통신의 한계와 이에 대한 대책을 위하여 실험한 것을 정리한 문서이다.

실험하기 위한 소스는 joinc.co.kr 의 UDS 소개 글에 있는 소스를 근간으로 해서 만들었다. 실험보드는 64M 메모리가 장착된 arm 보드에서 했다.

 

           2. 실험

2.1   UDS 누적 실험

UDS 누적 실험이란?

서버가 UDS 서버 소켓만을 열고 읽지 않을 경우
다른 클라이언트가 서버에게 통신을 일방적으로 보냈을때의 실험이다.

이때 사용되는 메모리는 어떻게 되는가?
프로세스는 어떤 현상이 생기는가?
전송된 순서는 분실되는가 등을 확인하는 실험이다.

실험 조건 및 방법

1) 서버용 프로세스는 UDS 서버 소켓을 만들고 bind 상태에서 무한 루프를 동작 시킨다.
2) 클라이언트 프로세스는 서버 소켓에 일방적으로 데이터를 보낸다.

실험 디렉토리 명은 send_limit_count 이다.

전송 크기를 (1 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (2 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (3 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (4 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (5 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (6 * 1024) 로 했을 경우에는 12 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (7 * 1024) 로 했을 경우에는 10 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.
전송 크기를 (8 * 1024) 로 했을 경우에는 9 번을 보내고 전송 루틴에서 블럭되는 현상이 발생했다.

결과

이 실험 결과로 추정할수 있는 것은
커널 내부에 저장될수 있는 UDS 패킷 수는12 개로 한정되어 있고
저장할수 있는 최대 크기 역시 존재한다는 것을 알수 있다.

그러므로 UDS로 프로세스간에 통신을 수행할때는 이런 점을 고려 해야 한다.

 

2.2   데이터 전송 크기 실험

전송 크기 실험이란?

데이터 전송 크기 실험이란 UDS에 아주 큰 데이터는 얼마까지 전송할수 있는 가를 확인하는 실험이다.

실험 조건 및 방법

서버는 최대 크기를 수신할수 있도록 하고 클라이언트는 크기별로 전송한다. 이때 전송 순서와 전송된 크기가 유지되는가 확인한다.

실험 디렉토리 명은 send_limit_size 이다.

결과

전송 크기를 (63 * 1024) 로 했을 경우에는 정상적으로 송신되고 수신되었으며 순서 역시 변경되지 않았다.
전송 크기를 (64 * 1024) 로 했을 경우에는 프로세스가 죽어 버리는 현상이 발생되었다.

이 실험 결과로 추정할수 있는 것은 전송할수 있는 최대 크기는 64K 이하로 63K 정도까지는 안전하게 전송할수 있는 것 같다. 또한 전송된 패킷은 크기가 64K 미만인 경우에는 분활되어 전송되거나 하는 현상은 발생하지 않는 것을 알수 있다.

 

2.3   송신 소켓을 매번 열고 송신 후 닫을 경우 실험

이번 실험은?

송신 소켓을 매번 열고 닫는 방식으로 전송했을 때 다음과 같은 사항을 체크한다.

실험 조건 및 방법

1) 실험 방법은 서버는 bind 이후에 약 10초 정도를 무한 루프를 돈다.
2) 클라이언트는 소켓을 열고 데이터를 전송후 소켓을 닫는다.

실험 디렉토리 명은 send_limit_size 이다.

결과

이 실험 결과 클라이언트는 패킷을 12 번을 보내고 블럭되었다. 내가 예상하고 있던것과 다르게 UDS 타입이 UDP 인 경우에도 서버측에 데이터를 전송하다가 블럭 된다.

전송에 대한 블럭을 방지하기 위해서는 sendto 함수의 flag 인자에 MSG_DONTWAIT를 주면 된다. recvfrom 함수 역시 마찬가지다.

서버가 존재 하지 않는지 아니면 전송 실패인지를 알기 위해서는 errno 값을 확인하면 된다.

EAGAIN (11) : 대기중
ECONNREFUSED (111) : 연결이 끊겼다.

 

2.4   송신 소켓을 매번 열고 닫는 방식으로 전송했을 때 소모 되는 시간은 얼마 인가?

이번 실험은?

송신 소켓을 매번 열고 닫는 방식으로 전송했을 때 소모 되는 시간을 측정한다.

실험 조건 및 방법

1) 실험 방법은 서버는 bind 이후에 약 10초 정도를 무한 루프를 돈다.
2) 클라이언트는 소켓을 열고 데이터를 전송후 소켓을 닫는다.
3) 2 번 과정의 시간을 측정한다.

실험 디렉토리 명은 send_time_reopen 이다.

결과

의외로 많은 시간이 걸린다.

4 m sec 가 걸린다. 흠...

arm 이라서 조금 느린듯 하다.

 

2.5   송신 소켓을 미리 열고 전송했을 때 소모 되는 시간은 얼마 인가?

이번 실험은?

송신 소켓을 미리 열고 전송했을 때 소모 되는 시간 시간을 측정한다.

실험 조건 및 방법

1) 실험 방법은 서버는 bind 이후에 약 10초 정도를 무한 루프를 돈다.
2) 클라이언트는 소켓을 열고 데이터를 계속 보낸다.
3) 2 번 과정의 시간을 측정한다.

실험 디렉토리 명은 send_time_open 이다.

결과

4 m sec 가 걸린다.

다시 여는 것과 시간 차가 별로 나지 않는다.

 

           3. 총론

UDS는 서버가 열려 있고 bind 상태이면,

  • 송신시 sendto 함수의 flag 인자에 MSG_DONTWAIT를 주지 않고 송신하고 서버가 바쁜 상태이면
    12 개 정도의 패킷 전송후 블럭된다.

  • 전송에 걸리는 시간은 4 m Sec가 소모된다.
    ( 1MByte 메모리 클리어 하는데 대략 10m Sec가 소모되는 프로세스의 속도로 보면 어쩔수 없는 속도로 보인다. )

  • 소켓은 미리 만들어 놓고 지속적으로 사용하거나 그때 그때 만드나 시간적인 속도의 차는 거의 없는 것으로 보인다.

  • 시스템 안정성도 크게 차이가 없다.

  • UDS 로 인한 시스템 메모리 문제가 발생하는 경우는 없는 것으로 판단된다.

 

태그: *UDS *IPC  *실험 *특성 *유영창

이 게시물을...