Skip to main content
The forwarder sink sends data to another Tell instance over TCP. Use it for edge-to-cloud deployments where edge nodes collect data locally and relay it to a central server.

​
Configuration

​
How it works

The forwarder receives batches from the router, rebuilds each FlatBuffer message with:
  • The remote server’s API key (replacing the local key)
  • The original client’s source IP preserved in the source_ip field
The remote Tell server receives the data as if the original client connected directly, preserving IP-based analytics.

​
Protocol

The forwarder uses the same length-prefixed FlatBuffer protocol as Tell’s TCP source:
The receiving server must have forwarding_mode = true on its TCP source to honor the source_ip field:
Without forwarding_mode, the central server would record the edge node’s IP instead of the original client’s IP.

​
Reliability

  • Auto-reconnect — reconnects automatically if the connection drops, with configurable retry intervals
  • Retry with backoff — 3 retry attempts per message with 1-second intervals
  • TCP keep-alive — enabled by default (30-second interval) to detect dead connections
  • Per-message forwarding — if one message fails, remaining messages in the batch still attempt delivery

​
Edge deployment pattern

A typical edge-to-cloud setup:
SDKs connect to the edge node. The edge node forwards everything to the central server. You can also add local sinks for redundancy: