SOME/IP
UDP or TCP
SOME/IP messages can travel over UDP (connectionless) or over TCP (connection-oriented). UDP is lean and fast but may lose a message; TCP never loses one but may make everything behind it wait.
Two ways to carry a message
UDP
Lean and quick
UDP (connectionless transport: each datagram travels on its own) does not repeat anything: a lost datagram is simply gone. Fine when the next value comes soon anyway, as with a cyclic update.
TCP
Reliable, in order
TCP (connection-oriented transport) carries a stream of bytes over a connection between two ECUs. Lost data is repeated, order is kept, duplicates are removed. Messages can be much larger.
Which one to use
The protocol specification gives a short guideline:
| Situation | Use |
|---|---|
| The receiver must react fast even when something is lost (well under 100 ms), for example cyclic values | UDP |
| Big data (more than about 1400 bytes) and no hard timing need when something goes wrong | TCP |
| Big data and a hard timing need when something goes wrong | UDP with SOME/IP TP, which cuts the message into segments (lesson 23) |
| Very large data such as files | Another transfer mechanism; SOME/IP may carry just a handle to it |
The choice is made per event and per method, not per service: a service can use UDP for some of them and TCP for others. One event, though, is not sent over both.
Rules for TCP
one per instance
One connection
A service instance uses at most one TCP connection between client and server for all its REQUESTs, RESPONSEs and events, plus at most one UDP socket connection and one multicast address.
client opens
The client opens and closes
The client opens the connection before its first REQUEST or SubscribeEventgroup over TCP, re-opens it when it breaks, and closes it when it no longer needs the service. The server does not close it when it stops offering its services; it leaves that to the client.
broken connection
Open calls time out
When the TCP connection is lost, every REQUEST still waiting for its RESPONSE is treated as timed out (E_TIMEOUT).
Two smaller points. The specification recommends switching off Nagle's algorithm (TCP collecting small writes before sending them together), to keep reaction times short. And because TCP is one long byte stream, a receiver that loses track of where messages start needs help: a sender may insert a Magic Cookie message (a fixed SOME/IP message that marks a message boundary) now and then, mainly so that test tools can find the message boundaries again.
Things to notice. With UDP the loss costs exactly one message and nothing else. With TCP it costs time for every message behind the lost one, until the repeat has arrived. That waiting is why fast-reacting data prefers UDP, and why big data with hard timing uses UDP with SOME/IP TP instead of TCP.
Check yourself optional
New terms in this lesson
| Term | Meaning |
|---|---|
| UDP | Connectionless transport: fast and lean, but a lost datagram is not repeated |
| TCP | Connection-oriented transport: lost data is repeated and order is kept, at the cost of delay |
| Nagle's algorithm | TCP collecting small writes before sending them together; SOME/IP recommends switching it off |
| Magic Cookie | A fixed SOME/IP message a sender may insert into a TCP stream so receivers can find the message boundaries again |
Source: SOME/IP Protocol Specification, R20-11, sections 4.1.2.10, 4.2.1 (UDP and TCP binding, magic cookies), 4.2.6.4 and 6.1 (choosing the transport protocol); SOME/IP-SD Protocol Specification, R20-11, section 4.1.2.6.