DoIP timeout 처리, Response Pending 제대로 이해해야 덜 헤맨다

DoIP 구현하다 보면 결국 여기까지 온다.

요청 보냈다
ECU 응답 기다린다
근데 바로 응답 안 온다

이때 timeout을 어떻게 처리하느냐가 꽤 중요하다.
특히 Response Pending(0x78) 을 제대로 처리 안 하면
멀쩡한 ECU도 실패처럼 보이기 시작한다.

오늘은 실무에서 많이 부딪히는
timeout 흐름만 짧게 정리해보자.

timeout 문제는 결국 “얼마나 기다릴 거냐”다

UDS는 요청-응답 기반이다.

즉:

요청 → 기다림 → 응답

근데 ECU가 항상 바로 응답하는 건 아니다.

예를 들면:

Flash 작업
내부 연산
EEPROM 접근
Security 처리

이런 건 시간이 걸린다.

그래서 UDS에는 원래부터
“잠깐 기다려라” 개념이 들어 있다.

Response Pending이 뭐냐

대표적인 게 이거다.

7F XX 78

예:

7F 31 78

이 뜻은 단순하다.

“요청은 받았고 처리 중이다. timeout 치지 말고 기다려라”

중요한 건 이거다.

실패가 아니다
정상 흐름일 수 있다

이걸 실패 처리하면 안 된다.

P2 / P2* 타이머 느낌만 잡자

UDS에서는 보통 이런 타이머를 본다.

P2 timeout

ECU가 “일반 응답”을 줄 때까지 기다리는 시간이다.

보통 짧다.

Request → Response

이 흐름 기준이다.

P2* timeout

이건 Response Pending 이후다.

Request
 → Response Pending
   → 실제 응답

즉:

ECU가 “기다려”라고 했으니까
더 길게 기다려주는 시간

이게 P2*다.

여기서 많이 하는 실수

이건 진짜 자주 본다.

1) 0x78 받고 바로 실패 처리

가장 흔하다.

7F XX 78

받자마자:

retry
reconnect
timeout 처리

이렇게 들어간다.

근데 ECU 입장에서는 아직 처리 중이다.

결과적으로 통신 흐름이 꼬인다.

2) timeout 값을 너무 짧게 둠

개발 환경에서는 괜찮은데
실차 가면 갑자기 timeout 터진다.

특히:

Flash
Coding
Security Access

이런 건 생각보다 오래 걸린다.

3) 무한 대기함

반대로 이것도 문제다.

Response Pending 계속 온다고
무한정 기다리면 안 된다.

적절한:

최대 retry 횟수
최대 wait 시간

이 필요하다.

실무에서는 이런 흐름으로 많이 간다

대충 이런 느낌이다.

send_request()

while timeout_not_expired():

    resp = receive()

    if resp == RESPONSE_PENDING:
        continue

    return resp

raise TimeoutError()

물론 실제 구현은 훨씬 복잡하지만,
핵심 흐름은 이렇다.

DoIP에서 더 헷갈리는 이유

CAN에서는 상대적으로 단순하게 느껴졌는데,
DoIP에서는 TCP까지 들어가니까 더 헷갈린다.

예를 들면:

TCP 연결은 살아 있음
근데 UDS 응답은 늦음

이 상황에서:

네트워크 문제인지
ECU 처리 지연인지

구분해야 한다.

이게 생각보다 어렵다.

디버깅할 때 보는 포인트

개인적으로는 이 순서로 본다.

1) TCP 연결 유지 중인가

연결 자체 끊겼으면
UDS 이전 문제다.

2) Response Pending 오는가

오면 ECU는 살아 있다.

즉:

요청 수신함
처리 중임

여기까지는 정상이다.

3) 최종 응답 오는가

결국 중요한 건 마지막이다.

Positive Response
Final NRC

이게 와야 transaction 종료다.

패킷 흐름 느낌으로 보면 이렇다

Tester → ECU
31 01

ECU → Tester
7F 31 78

(잠시 후)

ECU → Tester
71 01

이 흐름이면 정상이다.

중간에 0x78이 들어온다고 해서
실패가 아니다.

다음 글에서는 Security Access 쪽으로 가보자

timeout 흐름까지 이해했으면
이제 실무 냄새 나는 구간이 나온다.

다음은 이런 걸 보면 좋다.

Seed / Key 흐름
Security Access 실패 패턴
NRC 0x35 / 0x36
Unlock 이후 세션 흐름

여기서부터 진짜 ECU마다 개성이 나온다.

한 줄 요약

Response Pending(0x78)은 실패가 아니라 “처리 중” 상태이며, DoIP/UDS 구현에서는 P2/P2* timeout 흐름을 정확히 처리하는 게 중요하다.