WEB / WEB-04.03

Connection closure and UDP

Follow directional TCP closure through FIN/RST and read the different scope of UDP datagrams.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Ordinary FIN close

Both directions open
This fixture starts with earlier data already acknowledged; subsequent steps follow the selected FIN and half-close boundaries.
Client transport
ESTABLISHED; next SEQ=1007
Server transport
ESTABLISHED; next SEQ=7001
Client local close
The client finished sending; its peer has not received FIN.
Client transport
FIN-WAIT-1; FIN prepared SEQ=1007
Server transport
ESTABLISHED; next SEQ=7001
Client FIN at server
The server learned sender EOF and entered CLOSE-WAIT; its own application has not closed.
Client transport
FIN-WAIT-1; FIN prepared SEQ=1007
Server transport
CLOSE-WAIT; client EOF; ACK=1008 prepared
FIN ACK at client
The client learned its FIN was acknowledged and can still receive from the server.
Client transport
FIN-WAIT-2; ACK1008 received
Server transport
CLOSE-WAIT; client EOF; ACK=1008 prepared
Server local close
The server application also finished sending; LAST-ACK and FIN7001 are prepared.
Client transport
FIN-WAIT-2; ACK1008 received
Server transport
LAST-ACK; FIN prepared SEQ=7001
Server FIN at client
The client received peer EOF, entered TIME-WAIT and prepared ACK7002.
Client transport
TIME-WAIT; server EOF; ACK7002 prepared
Server transport
LAST-ACK; FIN prepared SEQ=7001
Final ACK at server
The server received acknowledgment of its FIN and closed; the client remains TIME-WAIT.
Client transport
TIME-WAIT; server EOF; ACK7002 prepared
Server transport
CLOSED; final ACK7002 received
Local 2×MSL boundary
The selected 60-second elapsed condition is local, not a packet; no OS clock is executed.
Client transport
CLOSED; selected 2MSL elapsed
Server transport
CLOSED; final ACK7002 received

Half-close reply

Both directions open
This fixture starts with earlier data already acknowledged; subsequent steps follow the selected FIN and half-close boundaries.
Client transport
ESTABLISHED; next SEQ=1007
Server transport
ESTABLISHED; next SEQ=7001
Client local close
The client finished sending; its peer has not received FIN.
Client transport
FIN-WAIT-1; FIN prepared SEQ=1007
Server transport
ESTABLISHED; next SEQ=7001
Client FIN at server
The server learned sender EOF and entered CLOSE-WAIT; its own application has not closed.
Client transport
FIN-WAIT-1; FIN prepared SEQ=1007
Server transport
CLOSE-WAIT; client EOF; ACK=1008 prepared
FIN ACK at client
The client learned its FIN was acknowledged and can still receive from the server.
Client transport
FIN-WAIT-2; ACK1008 received
Server transport
CLOSE-WAIT; client EOF; ACK=1008 prepared
Server response prepared locally
The CLOSE-WAIT server prepared response OK without its own FIN.
Client transport
FIN-WAIT-2; ACK1008 received
Server transport
CLOSE-WAIT; OK prepared SEQ7001 len2
Response data arrival
The client receives OK despite its closed sending direction; next expected server sequence is 7003.
Client transport
FIN-WAIT-2; received OK; ACK7003 prepared
Server transport
CLOSE-WAIT; OK prepared SEQ7001 len2
Response ACK arrival
The server received its data ACK; the trace ends before full close.
Client transport
FIN-WAIT-2; received OK; ACK7003 prepared
Server transport
CLOSE-WAIT; OK acknowledged; own FIN not sent

Local application abort

Established abort context
This branch describes a selected local abort of an existing connection.
Client transport
ESTABLISHED; next SEQ=1007
Server transport
ESTABLISHED; next SEQ=7001
Server local abort
The server application selected abort; local state closed and a valid reset indication is prepared.
Client transport
ESTABLISHED; next SEQ=1007
Server transport
CLOSED; local application abort; reset prepared
Valid reset arrival
An assumed-valid reset arrived at the client. The client is CLOSED; this is not a graceful FIN exchange.
Client transport
CLOSED; accepted valid reset; app not yet notified
Server transport
CLOSED; local application abort; reset prepared
Local application notification
The application learns the abort outcome, without proof of business rollback or peer commit.
Client transport
CLOSED; application notified of abort
Server transport
CLOSED; local application abort; reset prepared

UDP datagram

UDP datagram context
A UDP endpoint pair is selected; TCP state names do not apply.
Client transport
UDP 192.0.2.10:53000; datagram absent
Server transport
UDP 198.51.100.200:53001; datagram absent
Local PING preparation
ASCII PING occupies four bytes and the UDP header eight, giving length 12. No checksum number is supplied because a complete datagram is not encoded.
Client transport
UDP PING prepared; length=12
Server transport
UDP 198.51.100.200:53001; datagram absent
UDP datagram arrival
The selected datagram arrived at the server; UDP does not automatically generate ACK or an application reply.
Client transport
UDP PING prepared; length=12
Server transport
UDP PING received; boundary preserved; app unread
Local datagram read
The application consumes PING, without an invented PONG or delivery guarantee.
Client transport
UDP PING prepared; length=12
Server transport
UDP app read PING; no response modeled

ACTORS · STATE · DATA FLOW

Leaving established state proceeds separately by direction

TCP is full-duplex: an endpoint may finish sending while continuing to receive in the other direction. A CLOSE intent is distinct from FIN reaching the peer. Our example starts with earlier data acknowledged, client next sequence 1007, server next sequence 7001 and both peers ESTABLISHED.

A local client close enters FIN-WAIT-1. Its payload-free FIN at SEQ=1007 consumes one sequence position. On FIN arrival the server enters CLOSE-WAIT, while the client stays FIN-WAIT-1 until acknowledgment arrives. State names describe each endpoint’s knowledge rather than one global label.

FIN says the sender has no more data

The server acknowledges client FIN with ACK=1008. Arrival of that ACK moves the client to FIN-WAIT-2. If the server application has not closed its sending side, it may remain in CLOSE-WAIT and send response bytes. In the half-close branch it sends OK at SEQ=7001, making the client’s next expected position 7003.

FIN does not prove that no data remains in the other direction or that an application response is correct. An application supporting half-close can see EOF and still finish its response. Application/API choices can constrain this behavior; do not generalize the selected example to every socket API.

TIME-WAIT is still state in ordinary closing

In the normal branch the server application closes locally and enters LAST-ACK. Server FIN at SEQ=7001 moves the client to TIME-WAIT; arrival of ACK=7002 moves the server to CLOSED. Sending the final ACK does not immediately discard all client connection state.

TIME-WAIT accommodates old duplicate lifetimes and another final ACK if a FIN is retransmitted. The base TCP bound is 2×MSL; our MSL=30 seconds is visible arithmetic, not an OS default. FIN and ACK can be combined and simultaneous close follows another state path, so closure is not universally four separate packets.

RST is different from graceful closure

An accepted valid RST follows an abort path rather than the graceful FIN exchange that completes reliable delivery of queued data. Our selected cause is a local server-application abort. The server closes locally; the peer closes after receiving the assumed-valid reset and conveys abort information to its application.

A real trace containing RST alone does not identify a business failure cause. Endpoint state, sequence validation and application/OS context matter. Validity is a selected precondition here; neither packet encoding nor reset-validation algorithms are executed. Absence of RST likewise does not prove application success.

A UDP datagram does not carry TCP lifecycle states

UDP has an eight-byte header containing source/destination ports, length and checksum. Our ASCII PING payload is four bytes, giving UDP length 12 including its header. The IP header is excluded. This summary invents no numeric checksum; pseudoheader and complete-datagram computation are omitted.

UDP alone supplies no handshake, cumulative ACK, retransmission, ordered stream or FIN/RST lifecycle. An application may locally select a UDP socket peer without any TCP handshake on the wire. An upper protocol can define request/response, timeout and retry, but UDP itself does not provide them.

Datagram receipt is not an application operation

The UDP branch selects one successful arrival of a PING datagram at the server. Application consumption is a later local step; the server does not automatically generate PONG. One successful arrival proves neither guaranteed delivery nor the behavior of all UDP traffic.

The application must design any needed duplicate/reordering and retry handling. Transport choice does not establish user authorization or once-only execution. Separating connection lifecycle from datagram handling prevents assigning upper-protocol behavior to the wrong layer.

Read every scenario without motion

Half-close

Directional closure has a scope
The client closes its send direction with FIN while clientCanStillReceive=true. Peer EOF is not the end of the whole bidirectional exchange.
Transport evidence
Send closed / receive open
Lifecycle boundary
Application incomplete
Business outcome
No business outcome
No premature business outcome was given
The server is in CLOSE-WAIT and may send OK. Application protocol completion is kept separate from one-direction EOF.
Transport evidence
Send closed / receive open
Lifecycle boundary
Server response still possible
Business outcome
No business outcome
Data history was included
In the half-close example, the server sends two bytes OK from seq 7001, yielding expected ACK 7003. Normal payload-free server FIN uses ACK 7002 under another data history. Values are not copied blindly between branches.
Transport evidence
OK +2 → ACK7003 / FIN +1 separate
Lifecycle boundary
Server response still possible
Business outcome
No business outcome
Retry outcomes were not inferred from transport
Transport acknowledgment of OK does not establish a sufficient application response. This half-close branch has no RST; business completion and whether to retry an operation depend on the application contract.
Transport evidence
OK +2 → ACK7003 / FIN +1 separate
Lifecycle boundary
Server response still possible
Business outcome
Commit / retry authority unknown
Half-close retains its own final states
This branch ends before the server's own FIN. The client is FIN-WAIT-2 and the server CLOSE-WAIT, with OK acknowledged. TIME-WAIT and 2×MSL from ordinary closure are not the final states of this unfinished exchange.
Transport evidence
OK +2 → ACK7003 / FIN +1 separate
Lifecycle boundary
Client FIN-WAIT-2 / server CLOSE-WAIT
Business outcome
Commit / retry authority unknown
Closure did not expand business scope
The half-close trace ends before full closure. An open receive direction can be ordinary protocol behavior; no permanent failure is claimed.
Transport evidence
OK +2 → ACK7003 / FIN +1 separate
Lifecycle boundary
Client FIN-WAIT-2 / server CLOSE-WAIT
Business outcome
Half-close valid / completion separate

Abort boundary

Directional closure has a scope
Abort supplies local-server-application-abort and assumes reset validity for an existing connection. The RST flag does not establish an actual root cause.
Transport evidence
Selected abort / cause supplied
Lifecycle boundary
Application incomplete
Business outcome
No business outcome
No premature business outcome was given
A transport reset does not undo earlier application work. Processed bytes or commit require application-outcome evidence, not CLOSED state.
Transport evidence
Selected abort / cause supplied
Lifecycle boundary
Rollback not proven
Business outcome
No business outcome
Local abort is not peer receipt
The server application's local abort first closes its own TCP state. Before receiving the assumed-valid reset, the client remains ESTABLISHED. Both peers do not gain closure knowledge simultaneously; this branch contains no OK or FIN exchange.
Transport evidence
Server CLOSED / client awaits reset
Lifecycle boundary
Rollback not proven
Business outcome
No business outcome
Retry outcomes were not inferred from transport
After reset, queuedDataReliablyDeliveredClaimed=false. Safe/idempotent retry under unknown business completion depends on the application contract; this trace proves no once-only operation.
Transport evidence
Server CLOSED / client awaits reset
Lifecycle boundary
Rollback not proven
Business outcome
Commit / retry authority unknown
A valid reset skips graceful FIN stages
Arrival of the assumed-valid RST closes the client, followed by a local abort notification to its application. This abort branch does not execute graceful FIN, LAST-ACK or TIME-WAIT stages. CLOSED does not imply that earlier business work was rolled back.
Transport evidence
Server CLOSED / client awaits reset
Lifecycle boundary
Both endpoints CLOSED after valid RST
Business outcome
Commit / retry authority unknown
Closure did not expand business scope
Abort is not a graceful FIN exchange and establishes no transaction rollback. Transport closure is known; earlier application effects need separate evidence.
Transport evidence
Server CLOSED / client awaits reset
Lifecycle boundary
Both endpoints CLOSED after valid RST
Business outcome
Transport closed / business unknown

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: EOF ends the entire exchange

An application automatically closing its response direction on peer FIN may truncate an intended half-close exchange. The condition is treating one-direction EOF as completion of both directions.

Track sending, receiving and application-protocol completion separately. CLOSE-WAIT alone is not a failure diagnosis; duration and application context determine its meaning.

Broken assumption: reset rolls back earlier work

TCP abort does not automatically roll back application work already performed. The peer may have processed some bytes; RST ends transport state. The mistaken condition is interpreting transport abort as transaction rollback.

Define application outcomes and retry semantics at their own layer. A reset flag alone proves neither a business commit nor its failure cause.

Broken assumption: a UDP checksum means reliability

Checksum error detection differs from guaranteed delivery/ordering. Seeing a checksum field does not prove lost data was retransmitted or processed by an application.

State the required transport/application properties explicitly. A missing response does not mean UDP itself must generate an error reply.

Read every scenario without motion

FIN ledger

The transport-evidence type was selected
Ordinary active close starts with ESTABLISHED/ESTABLISHED and unacknowledgedDataAtStart=0. Simultaneous close is outside this trace.
Lifecycle evidence
Ordinary close / no outstanding data
Arithmetic review
No calculation
Outcome review
No conclusion
Byte or sequence arithmetic was done
Client FIN 1007 consumes one sequence and expects ACK 1008; server FIN 7001 expects ACK 7002. PayloadBytes=0 and sequenceSpaceUsed=1 are different fields.
Lifecycle evidence
Ordinary close / no outstanding data
Arithmetic review
FIN1007→ACK1008 / FIN7001→ACK7002
Outcome review
No conclusion
Arrival was separated from preparation
Local client close gives FIN-WAIT-1 while the server stays ESTABLISHED. Client FIN arrival makes the server CLOSE-WAIT; opposite-end ACK state is not imported early.
Lifecycle evidence
Local close ≠ peer arrival
Arithmetic review
FIN1007→ACK1008 / FIN7001→ACK7002
Outcome review
No conclusion
Normal final-state scope was preserved
Final ACK arrival gives server CLOSED and client TIME-WAIT; selected local 2MSL expiry separately closes the client. Each state has its own owner.
Lifecycle evidence
Local close ≠ peer arrival
Arithmetic review
Server closed / client waits separately
Outcome review
No conclusion
No missing higher-layer claim was added
FIN/ACK segments may be combined; four separate segments are not universal. Graceful TCP closure states are not imported into abort or UDP; no actual socket/API measurement follows from this ledger.
Lifecycle evidence
Local close ≠ peer arrival
Arithmetic review
Server closed / client waits separately
Outcome review
Different lifecycle profiles retained
Review finished within arithmetic scope
FIN arithmetic and endpoint-state order agree for the supplied ordinary-close example. Actual evidence needs FIN/ACK observations for the tuple and local CLOSE/timer records. This calculation measures neither application completion nor a real OS TIME-WAIT duration.
Lifecycle evidence
Local close ≠ peer arrival
Arithmetic review
Server closed / client waits separately
Outcome review
FIN states consistent / business unknown

UDP length

The transport-evidence type was selected
The UDP example uses client port 53000 and server port 53001 with four ASCII bytes PING. The header has sourcePort, destinationPort, length and checksum; TCP lifecycle states do not apply.
Lifecycle evidence
UDP / PING / no TCP states
Arithmetic review
No calculation
Outcome review
No conclusion
Byte or sequence arithmetic was done
An eight-byte UDP header plus four PING bytes gives length 12. No numeric checksum is supplied. The length calculation proves neither complete datagram encoding nor successful checksum verification.
Lifecycle evidence
UDP / PING / no TCP states
Arithmetic review
8+4=12 / checksum unknown
Outcome review
No conclusion
Arrival was separated from preparation
selectedSuccessfulArrival=true belongs only to the selected datagram. Local read and applicationResponseProduced=false remain separate; no transport ACK or automatic reply is produced.
Lifecycle evidence
Selected arrival / application response absent
Arithmetic review
8+4=12 / checksum unknown
Outcome review
No conclusion
Normal final-state scope was preserved
orderedReliableDeliveryProvidedByUDP=false. Presence of a checksum field proves neither retransmission, ordering nor application acceptance.
Lifecycle evidence
Selected arrival / application response absent
Arithmetic review
Checksum ≠ reliable delivery
Outcome review
No conclusion
Datagram and application evidence differ
The length field relates header and payload sizes only. Actual receipt needs a datagram observation for the relevant endpoint and tuple; an application read needs separate application evidence. This example selects one successful arrival, without covering loss, duplication or retries.
Lifecycle evidence
Selected arrival / application response absent
Arithmetic review
Checksum ≠ reliable delivery
Outcome review
Datagram receipt ≠ application outcome
Review finished within arithmetic scope
UDP length=12 agrees with the supplied field contract; network reliability and application response remain UNKNOWN. One successful arrival does not test every loss/duplicate case.
Lifecycle evidence
Selected arrival / application response absent
Arithmetic review
Checksum ≠ reliable delivery
Outcome review
Length agrees / no delivery guarantee

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Track +1 in the FIN ledger

Compute ACK1008 for client FIN=1007 and ACK7002 for server FIN=7001. Change only the receiver state at each arrival, rather than advancing the peer before its ACK arrives.

The half-close OK is two bytes and needs ACK7003. Do not blindly reuse FIN values across connections with different data histories.

Separate graceful and abort evidence

The normal branch shows FIN-WAIT-1/2, CLOSE-WAIT, LAST-ACK and TIME-WAIT for an ordinary close. The abort branch does not follow that sequence; its selected valid reset is a different event.

In an application review relate transport observations to completion and shutdown intent. The selected local timer here is not an OS measurement.

Check UDP length and scope by hand

Add the eight-byte header to PING’s ASCII byte count to obtain 12. The scene separates datagram arrival and local read without adding a transport ACK, FIN or automatic application reply.

If reliability is required, explain how an upper protocol provides it. One successful datagram arrival is not an implementation covering all loss/duplicate cases.

NOW APPLY IT TO THE CASE

Which acceptance stages are not completed by FIN, RST or UDP length?

The server can still send OK after client FIN. An abort does not automatically undo earlier business work. The 12-byte UDP PING example is only a field calculation for the selected datagram.

Where does the connection carrying the response differ from application outcome? Do not substitute network or transport evidence for body-parsing or DOM success.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Directional-close and datagram ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "context": {
    "tcpClient": "192.0.2.10:51000",
    "tcpServer": "198.51.100.200:443",
    "clientNextSeq": 1007,
    "serverNextSeq": 7001,
    "unacknowledgedDataAtStart": 0,
    "initialStates": [
      "ESTABLISHED",
      "ESTABLISHED"
    ]
  },
  "normalFin": [
    {
      "from": "client",
      "to": "server",
      "seq": 1007,
      "payloadBytes": 0,
      "sequenceSpaceUsed": 1,
      "expectedAck": 1008
    },
    {
      "from": "server",
      "to": "client",
      "seq": 7001,
      "payloadBytes": 0,
      "sequenceSpaceUsed": 1,
      "expectedAck": 7002
    }
  ],
  "normalStates": [
    {
      "event": "initial",
      "owner": 0,
      "client": "ESTABLISHED",
      "server": "ESTABLISHED"
    },
    {
      "event": "local-client-close",
      "owner": 0,
      "client": "FIN-WAIT-1",
      "server": "ESTABLISHED"
    },
    {
      "event": "client-fin-arrival",
      "owner": 1,
      "client": "FIN-WAIT-1",
      "server": "CLOSE-WAIT"
    },
    {
      "event": "fin-ack-arrival-at-client",
      "owner": 0,
      "client": "FIN-WAIT-2",
      "server": "CLOSE-WAIT"
    },
    {
      "event": "local-server-close",
      "owner": 1,
      "client": "FIN-WAIT-2",
      "server": "LAST-ACK"
    },
    {
      "event": "server-fin-arrival",
      "owner": 0,
      "client": "TIME-WAIT",
      "server": "LAST-ACK"
    },
    {
      "event": "final-ack-arrival-at-server",
      "owner": 1,
      "client": "TIME-WAIT",
      "server": "CLOSED"
    },
    {
      "event": "selected-2MSL-local-expiry",
      "owner": 0,
      "client": "CLOSED",
      "server": "CLOSED"
    }
  ],
  "timeWait": {
    "duration": "2*MSL",
    "selectedMslSeconds": 30,
    "selectedWaitSeconds": 60,
    "actualOsDefaultClaimed": false,
    "purpose": [
      "old-duplicate-lifetime",
      "allow-final-ACK-again-if-FIN-retransmitted"
    ]
  },
  "halfClose": {
    "clientSendClosed": true,
    "clientCanStillReceive": true,
    "serverStateAfterClientFin": "CLOSE-WAIT",
    "serverReply": {
      "seq": 7001,
      "payload": "OK",
      "payloadBytes": 2,
      "expectedAck": 7003
    },
    "serverFinNotYetSent": true,
    "traceEndsBeforeFullClose": true
  },
  "abort": {
    "selectedCause": "local-server-application-abort",
    "resetValidity": "assumed-valid-for-existing-connection-not-encoded",
    "receiverStateAfterValidReset": "CLOSED",
    "gracefulFinExchange": false,
    "queuedDataReliablyDeliveredClaimed": false,
    "realResetCauseDerivableFromFlagAlone": false
  },
  "udp": {
    "client": "192.0.2.10:53000",
    "server": "198.51.100.200:53001",
    "headerFields": [
      "sourcePort",
      "destinationPort",
      "length",
      "checksum"
    ],
    "headerBytes": 8,
    "payload": "PING",
    "payloadBytes": 4,
    "length": 12,
    "checksumNumericValue": "not-supplied; no complete datagram encoding",
    "selectedSuccessfulArrival": true,
    "orderedReliableDeliveryProvidedByUDP": false,
    "tcpLifecycleStatesApply": false,
    "applicationResponseProduced": false
  },
  "lifecycleScope": {
    "ordinaryActiveClose": true,
    "simultaneousClose": "not-modeled",
    "FINAndAckMayBeCombined": true,
    "fourSeparateSegmentsUniversal": false,
    "RSTInjectionOrLiveSocket": "not-performed"
  }
}

normalFin: FIN consumes one sequence position even without payload.
normalStates: Separate peer states for ordinary active close.
timeWait: 2×MSL with selected duration, not an OS default.
halfClose: The response direction may remain open after client sending ends.
udp.length: UDP header plus payload bytes, excluding IP header.

FIN/RST and UDP fields are semantic summaries only. No real sockets, pcap, checksums, timers or OS results are produced.

Two reality checks

Receiving peer FIN ends data in both directions.

FIN ends the sender’s direction. An endpoint supporting half-close can continue responses in the other direction.

Selecting a UDP socket peer creates a TCP-like handshake.

Local peer selection adds no SYN/ACK, FIN or delivery guarantee to UDP. Upper-protocol behavior is separate.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The client sent FIN; the server is in CLOSE-WAIT. Can the server still send OK?

Yes; the client receive direction remains open in the selected half-close.
No; one FIN closes both directions at once.

Read the explained answer

Yes; the client receive direction remains open in the selected half-close. — ClientSendClosed=true, clientCanStillReceive=true. The server FIN has not been sent yet.

How is UDP length=12 formed, and what does it say about a response?

Selected lesson artifact fields; teaching example

udp.headerBytes: 8
udp.payloadBytes: 4
udp.length: 12
udp.applicationResponseProduced: false

8 header bytes+4 PING bytes; an application response is not established.
A 12-byte application payload was received and a TCP ACK returned.

Read the explained answer

8 header bytes+4 PING bytes; an application response is not established. — Even with a selected successful arrival, applicationResponseProduced=false; UDP supplies no ACK/reliable reply.

Explain the evidence difference between observing RST in a record and this fixture’s local-server-application-abort branch.

Read the explained answer

The fixture supplies local application abort as the cause and assumes reset validity for the existing connection. A real RST flag alone does not establish the same cause. Reset is not a graceful FIN exchange and does not guarantee reliable delivery of queued data.

□ I distinguished the supplied cause from an observed flag.

□ I inferred no data-delivery guarantee from reset.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9293 — Transmission Control Protocol (TCP)3.1 Header Format; 3.4 Sequence Numbers · 3.3.2 State Machine Overview; 3.5.3 Reset Processing; 3.6 Closing a Connection; 3.6.1 Half-Closed Connections · 3.7 Segmentation; 3.8.1 Retransmission Timeout; 3.8.6 Managing the Window
RFC 768 — User Datagram ProtocolIntroduction; Format; Fields; User Interface
RFC 5737 — IPv4 Address Blocks Reserved for Documentation3 Documentation Address Blocks

YOUR NOTES / THIS BROWSER

Connection closure and UDP

1. Core · Mechanism

Ordinary FIN close

Half-close reply

Local application abort

UDP datagram

Leaving established state proceeds separately by direction

FIN says the sender has no more data

TIME-WAIT is still state in ordinary closing

RST is different from graceful closure

A UDP datagram does not carry TCP lifecycle states

Datagram receipt is not an application operation

2. Red · Trust & Impact

Half-close

Abort boundary

Broken assumption: EOF ends the entire exchange

Broken assumption: reset rolls back earlier work

Broken assumption: a UDP checksum means reliability

3. Blue · Secure development & defense

FIN ledger

UDP length

Track +1 in the FIN ledger

Separate graceful and abort evidence

Check UDP length and scope by hand

Which acceptance stages are not completed by FIN, RST or UDP length?

Two reality checks

The client sent FIN; the server is in CLOSE-WAIT. Can the server still send OK?

How is UDP length=12 formed, and what does it say about a response?

Explain the evidence difference between observing RST in a record and this fixture’s local-server-application-abort branch.

Sources and scope