Skip to content

tokio_transport: implement MSG_TRUNC-aware recv_from for UDP truncation detection #119

Description

@JustinKovacich

Context

`src/tokio_transport.rs:190-197`:

```rust
// datagram and returns only the bytes that fit — it does
// NOT expose a truncation flag. Surfacing a reliable
// `truncated: bool` here would require a platform-specific
// `recvmsg`/MSG_TRUNC path (libc + unsafe), which is
// deferred for now. Until then, this field is always
// `false` for the Tokio backend; callers must not rely on
// it for truncation detection. This is documented on
// `ReceivedDatagram::truncated`'s field doc.
```

Goal

Implement a platform-specific `recvmsg(MSG_TRUNC)` path on the Tokio backend so `ReceivedDatagram::truncated` reports honestly when the kernel silently truncated a UDP datagram larger than the caller's buffer.

Approach

Linux: `libc::recvmsg` + `MSG_TRUNC` flag. Darwin/BSD: `recvmsg` with the same flag. Windows: WSARecvFrom + `MSG_PARTIAL` (different flag, same semantic).

Wrap behind `cfg(unix)` / `cfg(windows)` blocks; fall back to the current `recv_from` (always-`false` truncated) if neither is available. Use `unsafe` libc calls; document the safety reasoning at the call site.

Triggering condition

A real consumer needs reliable UDP truncation detection on tokio. The embassy-net backend already surfaces it correctly; the gap is only on the std/tokio side.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestsimple_someipIssue related to the simple_someip crate

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions