---
id: network--tcp-server-plugin
title: "TCP server"
summary: "Listens for TCP connections on an address and port, emits all received data as `TcpDatagram` records and sends data back to a specific client through the `Response` pin. Use it to accept connections from devices or services that speak a raw TCP protocol. The component keeps the flow running."
audience: user
keywords: "start, request, response, tcp events, address, port"
---
# TCP server

Listens for TCP connections on an address and port, emits all received data as `TcpDatagram` records and sends data back to a specific client through the `Response` pin. Use it to accept connections from devices or services that speak a raw TCP protocol. The component keeps the flow running.

## Pins

| Pin | Kind | Types | Description |
|---|---|---|---|
| Start | start | any | Intended to start the server. When unconnected, the server starts with the flow (see Notes). |
| Request | output | `Viaducta.Plugins.UdpTypes.TcpDatagram` | Data received from a client, with new metadata. |
| Response | input | `Viaducta.Plugins.UdpTypes.TcpDatagram` | Data to send to a client, identified by `SessionId`. |
| Tcp events | continue | `Viaducta.Plugins.UdpTypes.TcpEvent` | Intended for client connect / disconnect events (see Notes). |

## Configuration

| Field | Type | Default | Description |
|---|---|---|---|
| `Address` | string | `127.0.0.1` | Required. Local IP address or host name to listen on. `127.0.0.1` accepts only local connections; use the machine's IP (or `0.0.0.0` / `*`) for remote clients. |
| `Port` | integer (1-65535) | `7000` | Required. Port to listen on. |

## Behaviour

- The server starts when the flow starts (with `Start` unconnected) and stops when the flow stops.
- Every chunk of data received from a client is emitted on `Request` as a `TcpDatagram`, processed in the background (several chunks can be processed in parallel):
  - `SessionId` and `IP`: the client's `ip:port` string,
  - `Port`: always `0`,
  - `Data`: the received bytes.
- There is no framing: a client message can be split over several datagrams, or several messages can arrive in one. Reassemble downstream if your protocol needs it.
- To answer, send a `TcpDatagram` to `Response` with the `SessionId` of the request and the bytes in `Data`. Keep `SessionId` from the request (a mapper that copies it). A missing `SessionId` throws an exception; a client that has already closed the connection is ignored.

## Notes

- Connecting the `Start` pin breaks the component: the server is then never started (an internal flag is never set), and `Response` fails. Leave `Start` unconnected.
- `Tcp events` is never called: connect / disconnect events are not emitted in the current code. When it works, `TcpEvent.Kind` is `1` CLIENT_CONNECTED or `2` CLIENT_DISCONNECTED, `Address` is `ip:port` and `Port` is `0`.
- Responses are written as they are; add your protocol's delimiter (for example `\r\n`) to `Data` yourself.

## Example

```json
{ "Address": "0.0.0.0", "Port": 7000 }
```

**TCP server** `Request` → (decode `Data`, build answer, keep `SessionId`) → **TCP server** `Response`