SOME/IP은 헤더의 Message Type 필드로 서로 다른 통신 패턴을 구분한다. 헤더 필드 자체는 SOME/IP에서, 파라미터를 바이트열로 바꾸는 규칙은 SOME/IP Serialization에서 다룬다.
전송 계층 바인딩
SOME/IP 메시지는 구성에 따라 UDP 또는 TCP로 전송된다. 차량에서 실제로 쓰는 포트 번호는 인터페이스 명세(FIBEX·ARXML 등)가 정해야 하고, ECU가 포트 번호를 동적으로 골라야 하면 IETF·IANA가 정한 임시(ephemeral) 포트 범위 49152~65535를 따라야 한다. 인터페이스 명세가 달리 정하지 않았다면, SOME/IP 구현은 관례적으로 포트 30491을 동적 클라이언트 포트로, 포트 30501을 첫 서버 포트로 쓰고 추가 서버 인스턴스에는 30502·30503처럼 순서대로 포트를 배정한다[1].
같은 서비스의 인스턴스가 여러 개면, 각 인스턴스는 서버 쪽 전송 계층 포트로 구분된다[2].
TCP는 메시지 경계가 없으므로, 테스트 도구가 SOME/IP 메시지의 경계를 다시 찾을 수 있도록 TCP 스트림에 Magic Cookie 메시지를 주기적으로 끼워 넣을 수 있다[2].
Magic Cookie는 일반 SOME/IP 헤더 필드에 다음과 같은 고정값을 채워 만든다[2]:
| 필드 | 클라이언트 → 서버 | 서버 → 클라이언트 |
|---|---|---|
| Message ID | 0xFFFF 0000 | 0xFFFF 8000 |
| Length | 0x0000 0008 | 0x0000 0008 |
| Request ID | 0xDEAD BEEF | 0xDEAD BEEF |
| Protocol Version | 0x01 | 0x01 |
| Interface Version | 0x01 | 0x01 |
| Message Type | 0x01 | 0x02 |
| Return Code | 0x00 | 0x00 |
Request/Response
가장 기본적인 통신 패턴으로, 클라이언트가 요청(REQUEST, 0x00)을 보내면 서버가 응답(RESPONSE, 0x80)으로 답한다 — 오류가 발생하면 서버는 RESPONSE 대신 ERROR(0x81)를 돌려보낸다[2].
서버는 요청의 Message ID·Request ID·Interface Version을 그대로 응답에 복사하므로, 클라이언트는 여러 요청을 동시에 보내도 각 응답을 올바른 요청과 짝지을 수 있다[2].
Fire & Forget
응답을 기대하지 않는 요청은 Fire & Forget이라 부른다. Message Type을 REQUEST_NO_RETURN(0x01)으로 설정한다는 점만 제외하면 REQUEST와 구현이 같지만, 서버는 응답을 보내지 않고 오류도 보고하지 않는다 — 오류 처리가 필요하면 애플리케이션이 직접 구현해야 한다[2].
Notification과 Field
Notification은 Publish/Subscribe 패턴이다. 구독 자체는 SOME/IP이 아니라 SOME/IP-SD가 처리하고, 구독이 성립한 뒤 값이 갱신되거나 이벤트가 발생하면 서버가 SOME/IP로 NOTIFICATION(0x02) 메시지를 보내 알린다[2].
같은 ECU에 서로 다른 클라이언트가 여러 개 구독 중이면, 통신 매체의 전송량을 아끼기 위해 알림을 복제해 모든 구독자에게 전달해야 한다[2].
Field는 getter·setter·notifier 중 최소 하나를 반드시 포함하는 조합이다[2].
Getter는 빈 Payload로 요청을 보내고 응답 Payload에 실린 값을 받는 Request/Response 호출이고, Setter는 원하는 값을 요청 Payload에 담아 보내고 실제로 반영된 값을 응답 Payload로 돌려받는 Request/Response 호출이며, Notifier는 구독 직후 초기값을 이벤트로 보내고 이후 변경 때마다 Notification 규칙을 그대로 따른다[2].
오류 처리
SOME/IP은 두 가지 방식으로 오류를 전달한다 — 메서드 응답(RESPONSE)의 Return Code 필드, 그리고 별도의 ERROR 메시지다[2].
REQUEST·REQUEST_NO_RETURN·NOTIFICATION 타입은 Return Code를 항상 0x00으로 고정하고, RESPONSE·ERROR 타입만 SOME/IP가 정의하는 실제 오류 코드를 담을 수 있다. 더 상세한 오류 정보(예: 예외 메시지 문자열)가 필요하면 ERROR 메시지(Message Type 0x81)를 RESPONSE 대신 보낸다 — 반대로 알림·Fire & Forget 메시지에는 ERROR로 응답하지 않는다[2].
신뢰성 의미론
RPC 메시지 전달이 얼마나 신뢰할 수 있는지는 세 단계로 구분된다[2]:
| 용어 | 의미 |
|---|---|
| Maybe | 메시지가 상대에게 도달할 수도, 안 할 수도 있다 |
| At least once | 메시지가 최소 한 번은 도달한다 |
| Exactly once | 메시지가 정확히 한 번 도달한다 |
SOME/IP은 UDP를 쓸 때 “Maybe” 신뢰성을, TCP를 쓸 때 “Exactly once” 신뢰성을 얻는다 — 그 이상의 오류 처리는 애플리케이션 몫이다. UDP 기반 Request/Response에서 클라이언트가 응답을 기다리다 타임아웃하면, SOME/IP 구현은 E_TIMEOUT을 애플리케이션에 알린다[2].