Such a simple task. I want a service. I will just open a connection to a provider of that service, and close it when I am done.

Such a difficult task. Who provides the service? How do they provide the service? How will my firewall know the service should be allowed? In fact, who decides when the service is done?

That is our topic for today. To assess the situation, at the transport level, regarding connections to services.

These are easy. We have already seen them in action in some of our stak traces. There is a 3-way handshake, which assumes that a potential server is acting as a listener and waiting for someone to try to connect.

A client sends a connect, which essentially is a TCP packet with the SYN flag set. It is destined to a well-known port, determined by the service that it wants, and there is no negotiation regarding the service to be provided, the listener can only provide that single service.

The listener accepts the request to connect, and returns its own packet which has the sYN flag and the ACK flag set. And from now on the listener will act as a server.

The client returns an ACK for the server's SYN packet, and from now on the two peers operate on an equal footing.

When one peer decides not to send any more it sets the FIN flag in a packet, and its partner sends an ACK for that FIN.

At some point the partner decides not to send any more, and it sets the FIN flag in a packet, the partner sends an ACK. and now the connection is totally closed and both ends release all resources associated with it.

In case you were wondering "what service" and "who talks first" regarding the service, and all sorts of questions of that sort, they are all settled by the two user programs that are running on top of the TCP connection. With HTTP for example the client sends a query and that is the first real data sent over the connection. With SMTP the server first sends a messages telling about itself, and the client then begins a dialogue.

We can simplify this topic: there is no such thing as far as UDP is concerned as a connection. There is no state kept at either peer (at least TCP remembers whether it has connected or not, and keeps track of sequence and acknowledgement numbers at each end).

Protocols that are users of UDP usually depend upon some other protocol for setting up a session. This other protocol (often called or thought of as a "signalling" protocol) is usually stream-based, and maybe even based on TCP. We will look at several ways in which this might be done.

This introduces a new topic, important in networking in many ways, that of middleboxes. They are what perhaps they sound like they are, boxes that are in the middle of a flow. We usually think of networked applications in terms of end-to-end flow, and middleboxes require us to change that thinking.

A typical middlebox is a network address translator (NAT).