When UDP packets arrive but expected transactions do not, investigate the receiver in layers: network arrival, socket delivery, shred validation, reconstruction, transaction parsing, downstream queues and canonical outcome reconciliation. A healthy packet counter proves only the first part of that path.
This guide is for operators who already have a shred receiver. If you have not bound a socket or verified delivery yet, start with our Rust and Go UDP receiver guide.
First define “missing”
Write down the transaction signature, relevant slot or observation interval, expected source and the place where you first noticed the absence.
These are different incidents:
- Your network interface did not see the expected traffic.
- The interface saw datagrams that the application did not read.
- The application received fragments but could not reconstruct a usable range.
- Reconstruction produced bytes that your parser rejected.
- A decoded observation arrived but was dropped downstream.
- You expected an executed transaction that was never canonical.
Do not use a later explorer view as proof that every intermediate observer received the same fragments at the same time. Preserve evidence from your own pipeline before restarting away the counters and queue state.
1. Check the selected destination and listening socket
For Shredo Raw Shreds, confirm the public IPv4 and UDP port saved in the console, the relay-confirmed destination and whether delivery is paused or stopped. Check that your receiving process is actually bound to the intended local address and port.
On a Linux receiver with iproute2 installed:
ss -u -a -n -p -m 'sport = :20000'
ip -s link show
Replace 20000 with your port. These commands inspect state; they do not change firewall rules or routing. Process details may require appropriate permissions.
A TCP connectivity test does not validate a UDP receiving path. Likewise, an outbound connection from the server does not establish that unsolicited inbound datagrams reach the application.
2. Separate interface arrival from application delivery
Take a short, bounded capture on the receiving host:
sudo tcpdump -ni any -c 100 'udp dst port 20000'
This can reveal sensitive packet data, so keep captures private and follow your operator policy. Do not publish them in a support ticket without reviewing the contents. A capture tool can drop packets too; its own summary is part of the evidence.
If no traffic is visible, investigate the configured destination, delivery state, host and provider firewalls, NAT and route. If traffic is visible but application counters stay flat, investigate binding and socket consumption before changing the shred parser.
3. Measure socket pressure before increasing buffers
Inspect the kernel's current settings and UDP counters:
sysctl net.core.rmem_default net.core.rmem_max
netstat -su
Compare counters over a specific interval. Host-wide error totals are not attributable to your process without additional evidence.
Linux exposes receive-buffer controls and a socket-drop ancillary counter through SO_RXQ_OVFL; these have different scopes. The socket manual documents those interfaces. Record the effective buffer reported by the operating system rather than assuming a requested value was applied exactly.
A larger buffer absorbs bursts. It cannot make a consumer that is consistently slower than the sender keep up indefinitely. Measure receive rate, processing rate and queue age together.
4. Check datagram truncation
UDP is message-oriented: a short application buffer can truncate a datagram. The Linux UDP manual describes receive truncation and the associated flag.
Use a receiving API that exposes truncation information where possible, and size buffers for the actual transport contract. Count oversized or truncated datagrams separately from malformed shreds. Increasing the kernel's socket queue does not increase the byte slice supplied to an individual receive call.
Do not concatenate two datagrams to “repair” a parse error. Datagram boundaries and shred identities belong in your input contract.
5. Instrument reconstruction, not just packet intake
Expose distinct counters for accepted shreds, rejected variants, duplicates, conflicting payloads, reconstruction failures and successfully parsed transactions. Keep slot/range context with errors, using sampled logs rather than a log line for every packet.
A repeated shred does not necessarily add new information. A conflicting payload must not be silently combined with another variant. Reconstruction may tolerate some missing data under its coding rules, but one received shred does not establish that a whole slot is complete.
Validate the supported shred variants and reconstruction logic against the implementation and network you actually consume. A UDP receiver example is not a complete FEC reconstructor or a proof of protocol compatibility.
If your receiver began failing after a release, keep a bounded private fixture that reproduces the failure and compare parser/reconstructor versions. Do not label every unsupported variant a network-loss incident.
6. Locate the first downstream loss point
A useful internal evidence chain is:
datagrams read → valid shreds → reconstructed ranges
→ parsed transactions → queued observations → strategy inputs
Count at each boundary. If parsed-transaction counts rise while strategy-input counts do not, changing the network buffer will not fix that boundary.
Move expensive JSON formatting, database writes and strategy evaluation out of the receiving loop. Use bounded queues with explicit overflow behaviour and measure their age. A queue that is not full can still be serving data too old for the strategy.
For duplicate handling, retain enough context to distinguish replayed observations from independent occurrences. Do not use an unbounded set of every signature ever seen.
7. Reconcile with execution separately
Shreds and reconstructed transactions are observations, not final outcome records. If a strategy needs canonical success or actual token-balance changes, join against an appropriate execution source.
Investigate dropped forks and observation timing before declaring an omission by the feed. Conversely, do not dismiss a receiver gap merely because some transactions from the interval eventually landed.
Record how long an interval remains incomplete, how recovery affects strategy eligibility and whether any independent state source can rebuild the information you need. Recovery is an application policy, not a property supplied by an extra reconnect.
What changes with Shredo Decoded Transactions?
Raw Shreds provides deduplicated UDP shreds to one configured IPv4:port. Its base subscription does not include reconstruction or historical replay.
Decoded Transactions moves transaction observations to an authenticated gRPC stream. You still need receiving capacity, bounded processing and explicit continuity handling. Handle gap events and a changed stream_id; reconnecting is not historical recovery.
If account resolution cannot support a reliable filtered decision, the documented service can report a gap. That is evidence of an incomplete interval, not proof that no matching transaction existed. Diagnose the stated condition instead of treating every gap as packet loss.
A compact incident checklist
| Evidence | Next investigation |
|---|---|
| No interface traffic | Destination, delivery state, firewalls and route |
| Interface traffic, no socket reads | Binding, receive errors and process health |
| Rising socket-drop counters | Consumption rate, bursts and effective buffers |
| Reads healthy, reconstruction failing | Truncation, missing fragments, variants and conflicts |
| Parsing healthy, strategy starved | Queue overflow, backpressure and downstream work |
| Observation present, outcome missing | Execution status and canonical reconciliation |
Frequently asked questions
Does receiving packets prove that my shred feed is complete?
No. It proves that some datagrams reached the observation point. Completeness requires more evidence through reconstruction and continuity checks.
Will increasing the receive buffer solve packet loss?
It may help with bursts. It does not fix every loss point or a sustained processing deficit.
Should I restart the receiver immediately?
Capture the relevant counters, configuration and bounded diagnostic evidence first when safe. A restart can erase the information needed to locate the loss point.
Were these Linux commands run against Shredo production?
No. They are operator diagnostics to run on your own receiving host. This article is not a live-feed E2E or a performance benchmark.