What a `Socket` is

A socket is a connection, not a protocol

A socket is one end of a live TCP connection between two hosts. That is the whole idea, and the thing most people get wrong is what it is not: a socket knows nothing about HTTP, or SMTP, or the dictionary protocol. It moves bytes in order, reliably, in both directions, and it stops there. Everything above that — what the bytes mean, who speaks first, what ends a message — is the protocol, and the protocol lives in your code.

A socket can do seven things: connect to a remote machine, send data, receive data, close the connection, bind to a port, listen for incoming connections, and accept them. Java splits those seven across two classes. java.net.Socket does the first four, which is exactly what a client needs. The last three are a server's job and belong to ServerSocket, which is the next module. So for now: a Socket is a client's connected endpoint.

Constructing it is connecting

new Socket("www.example.com", 80) does not create an idle object you connect later. The constructor performs the TCP three-way handshake and does not return until the connection is established — or throws UnknownHostException if the name will not resolve, or an IOException if the connection fails. This blocking behaviour surprises people; it is also why the socket is either usable or absent, never half-built.

Once connected, the link is full duplex: both ends may send and receive at the same time. Most protocols choose not to, and take strict turns instead, but the transport does not require it.

The two streams, and the one close

A connected socket hands you the two byte streams that carry the conversation:

• getInputStream() — an InputStream of the bytes the peer sent you.
• getOutputStream() — an OutputStream for the bytes you send.

These are raw byte streams. You chain them exactly as in Module 2: buffer them, wrap them in a Reader/Writer with an explicit charset for a text protocol, or a DataInputStream for a binary one.

Here is the rule that survives everything else in this lesson: the socket and its two streams are one resource. socket.close() closes both streams. Closing either stream closes the socket, and therefore the other stream too. So put the socket in the try-with-resources header, never a stream you derived from it, and you get correct cleanup on every path including the exceptional ones.

Worked example — HTTP by hand, over a raw socket

Module 5 taught the HTTP exchange as wire text. A socket is how you actually send that text. Connect to port 80, write a request line, a Host header, Connection: close, and a blank line; flush; then read until the stream ends. Because you asked for Connection: close, the server closes when the response is complete, and your read returns end-of-stream — that is what tells you the reply is finished.

Nothing in the code below knows it is speaking HTTP. Swap the port and the text and the same seven lines speak SMTP. That is the point of the abstraction: one transport, every application protocol.