ConnectionFisherServer

ConnectionFisherServer is the server-side peer for ConnectionFisherClient. It waits for the fixed client probe, replies with the fixed server marker, and only then allows the line to become a normal forwarding stream.

Use it only on paths that are expected to receive traffic from ConnectionFisherClient.

Typical Placement

Simple TCP layout:

TcpListener -> ConnectionFisherServer -> TcpConnector

Paired with the client:

TcpListener -> ConnectionFisherClient -> TcpConnector
TcpListener -> ConnectionFisherServer -> TcpConnector

With other stream tunnels in between:

ConnectionFisherClient -> EncryptionClient -> TcpConnector
TcpListener -> EncryptionServer -> ConnectionFisherServer -> TcpConnector

The server must see the same FISH? bytes that the client sends after any intermediate client/server tunnel pair has decoded them.

What It Does

• Initializes local line state on upstream Init.
• Delays upstream Init toward next.
• Buffers upstream bytes until the first 5 bytes are available.
• Requires the first 5 bytes to be FISH?.
• Sends the fixed reply FISH! downstream to the client.
• Initializes next only when post-probe payload is available.
• Forwards payload normally after the probe phase is complete.
• Closes the line on invalid probe data or oversized handshake buffering.

ConnectionFisherServer is a middle stream tunnel. It does not create sockets directly and it does not create packet lines.

Configuration Example

{
  "name": "fisher-server",
  "type": "ConnectionFisherServer",
  "next": "service"
}

settings is not used by the current implementation.

Required Fields

Top-level fields:

Field	Type	Description
name	string	User-chosen node name. Must be unique inside the config file.
type	string	Must be exactly "ConnectionFisherServer".
next	string	Required. The next stream node receives payload after the probe phase.

ConnectionFisherServer must also have a previous node in the chain. It is not a chain head or chain end.

Settings

No settings fields are currently parsed.

Probe Exchange

Direction	Bytes	Meaning
client to server	FISH?	Required first 5 upstream bytes.
server to client	FISH!	Reply sent after a valid probe.

The markers are fixed ASCII bytes. They are not a security mechanism.

Server Phases

The implementation uses three phases:

Phase	Behavior
wait ping	Upstream bytes are buffered until at least 5 bytes are available.
wait payload	The probe was valid and FISH! was sent, but next is not initialized yet unless extra payload is already buffered.
established	next has been initialized and payload/lifecycle callbacks are forwarded normally.

Handshake Flow

On upstream Init, the server only initializes its own line state. It does not call tunnelNextUpStreamInit() yet.

On upstream payload before establishment:

1. The server buffers incoming bytes.
2. If the handshake buffer exceeds 4096 bytes, the line is closed.
3. Once at least 5 bytes are available, the first 5 bytes are read.
4. If they are not exactly FISH?, the line is closed.
5. If they match, FISH! is sent downstream to the previous side.
6. If payload remains after the first 5 bytes, the server initializes next and forwards the remaining payload upstream.
7. If no extra payload remains, the server waits until the next upstream payload arrives, then initializes next and forwards that payload.

After next has been initialized, the line is considered established by this tunnel and later payload is forwarded normally.

Lifecycle Behavior

Before establishment:

• upstream Init is local only
• upstream payload is treated as probe or first post-probe payload
• upstream Pause and Resume are not forwarded
• downstream Est, Pause, and Resume are not forwarded
• downstream payload is unexpected, recycled, and causes the line to close

After establishment:

• upstream payload is forwarded to next
• downstream payload is forwarded to the previous node
• upstream pause/resume are forwarded to next
• downstream est/pause/resume are forwarded to the previous node

On upstream Finish, the server destroys local state and only forwards upstream Finish if next had already been initialized. On protocol error before next exists, it closes only the previous side because there is no next-side line yet.

Limits

Limit	Value	Behavior
Probe length	5 bytes	The first bytes must be FISH?.
Handshake buffer	4096 bytes	Line closes if more bytes accumulate before the probe can complete.
Required left padding	0	The server does not prepend to existing payload buffers.

The FISH! reply is allocated as a separate small buffer.

Notes and Caveats

• Use it with a matching ConnectionFisherClient.
• Place it after any server-side tunnel that decodes the transport used between the client and server.
• It is intended for stream-style chains, not packet-line chains.
• The probe is fixed and public; use other WaterWall nodes for real security.
• Upstream Est and downstream Init are disabled callbacks for this node.