Racket

someip: a SOME/IP protocol stack in pure Racket🔗ℹ

turlamai

package: someip

This package implements the AUTOSAR SOME/IP family of protocols — the message format, SOME/IP-TP segmentation, SOME/IP-SD service discovery, UDP/TCP transport, and provider/consumer APIs — in pure Racket on the standard distribution.

The implementation follows the AUTOSAR Foundation specifications (SOME/IP Protocol and SOME/IP-SD, release R22-11) and is validated byte-for-byte against the specification’s own examples in the test suite.

1 Layering🔗ℹ

(someip message) — the 16-byte header codec, message types, return codes, session id handling, TCP magic cookies.
(someip serialize) — payload serialization: primitives, BOM-carrying strings, arrays, structs, unions, TLV.
(someip tp) — SOME/IP-TP segmentation and reassembly.
(someip sd/message) — SOME/IP-SD entries and options.
(someip sd/machine) — SD server and client state machines, driven by injectable timers.
(someip transport) — UDP/TCP endpoints, multicast, packed-message splitting.
(someip provider) — methods, events, fields, SD offer.
(someip consumer) — calls with request/response matching, event callbacks, SD discovery.

2 Quick start🔗ℹ

2.1 Provider🔗ℹ

(require someip)
(define ep (make-someip-endpoint
            #:udp-port 30490
            #:multicast-groups '("239.255.1.100")
            #:message-handler void))
(define provider
  (make-service-provider
   #:endpoint ep
   #:service-id 17185
   #:instance-id 1
   #:interface-version 1
   #:methods
   (list (method 1
                 (lambda (payload sender)
                   (bytes (add1 (bytes-ref payload 0))))))
   #:events (list (event 32784 1))
   #:multicast-address "239.255.1.100"))
(provider-start! provider)

Inbound traffic is routed by composing the provider’s handler with the endpoint’s message-handler argument; see provider-message-handler.

2.2 Consumer🔗ℹ

(require someip)
(define ep (make-someip-endpoint
            #:multicast-groups '("239.255.1.100")
            #:message-handler void))
(define consumer
  (make-service-consumer
   #:service-id 17185
   #:interface-version 1
   #:eventgroup-ids '(1)
   #:multicast-address "239.255.1.100"))
(consumer-attach-endpoint! ep consumer)
(consumer-start-discovery! consumer)
(define result (consumer-call consumer 1 #:payload (bytes 20)))

3 Wire conformance and deviations🔗ℹ

The stack is validated against the specification’s own worked examples: the 5880-byte SOME/IP-TP segmentation walkthrough, the SD example PDU (Figure 5.2 of the SD specification) and the TCP magic cookie layouts.

Known spec-text conflicts are resolved and documented in the source: the SD entry types for subscribe/ack are 0x06/0x07 per the normative field definitions (the summary table’s 0x02/0x03 is a specification typo); stop-offer / stop-subscribe / nack are the offer/subscribe/ack types with TTL 0.

Documented simplifications: the SD server answers every find with a unicast offer (the specification’s basic behavior; the multicast-answer optimization is not implemented), and the consumer restarts its find cycle when an offer’s TTL expires.

4 Deterministic testing🔗ℹ

The SD machines take injectable timer managers, random sources and send callbacks, so the whole discovery lifecycle is tested deterministically with a virtual clock (see private/timers). The transport layer is tested over the loopback interface, including an end-to-end discovery → subscribe → call → event scenario.

1	Layering
2	Quick start
3	Wire conformance and deviations
4	Deterministic testing