- The client sends the server a DCCP-Request packet specifying
the client and server ports, the service being requested, and any features
being negotiated, including the CCID that the client would like the server
to use. The client may optionally piggyback some data on the
DCCP-Request packet, an application-level request, say, which the
server may ignore.
- The server sends the client a DCCP-Response packet indicating
that it is willing to communicate with the client. The response indicates
any features and options that the server agrees to, begins or continues
other feature negotiations if desired, and optionally includes an Init
Cookie that wraps up all this information and which must be
returned by the client for the connection to complete.
- The client sends the server a DCCP-Ack packet that acknowledges
the DCCP-Response packet. This acknowledges the server's initial
sequence number and returns the Init Cookie if there was one in
the DCCP-Response. It may also continue feature negotiation.
- Next comes zero or more DCCP-Ack exchanges as required to
finalize feature negotiation. The client may piggyback an
application-level request on its final ack, producing a DCCP-DataAck
packet.
- The server and client then exchange DCCP-Data packets,
DCCP-Ack packets acknowledging that data, and, optionally,
DCCP-DataAck packets containing piggybacked data and acknowledgements.
If the client has no data to send, then the server will send DCCP-Data
and DCCP-DataAck packets, while the client will send DCCP-Acks
exclusively.
- The server sends a DCCP-CloseReq packet requesting a close. (Only
the server can do this. L.B.).
- The client sends a DCCP-Close packet acknowledging the close.
- The server sends a DCCP-Reset packet whose Reason field
is set to "Closed", and clears its connection state.
- The client receives the DCCP-Reset packet and holds state for a
reasonable interval of time to allow any remaining packets to clear the
network.
|