HTTP Protocol Basics
A protocol is a set of precise communication rules.
A Connection That Behaves Like a File
Imagine two programs that need to exchange data. A socket gives them a two-way connection: either program can read data and either program can write data. This makes a socket resemble a file in the way a program performs reading and writing, but the destination is different. A file connects a program to local stored data, while a socket connects a program to another program.
The Waiting State
Reading from a file and reading from a socket can look similar to a program, but a socket has an important additional behavior. If a program tries to read from a socket when no data is available, the program blocks and waits for the other program to send data. The read does not immediately produce data because there is no data ready to receive.
Two Programs Waiting
Program A and Program B are connected through a socket. Both programs attempt to read before either program sends data.
- 1Program A reads
No data is available, so Program A blocks and waits for Program B to send data.
- 2Program B reads
No data is available for Program B either, so Program B also blocks and waits for Program A to send data.
- 3The communication stops
Both programs are waiting for the other program to act. This is the deadlock risk that communication rules must prevent.
If both programs wait for data before sending anything, neither program reaches the action that would release the other.
Rules That Keep Messages Moving
A protocol is a set of precise communication rules. It specifies the sequence of communication, including who sends first, what is sent, what response is expected, and who sends next. These rules give both programs the same expectations about the conversation. Because each program knows when it should send and when it should read, the rules help prevent deadlock and keep communication orderly.
The Communication Sequence
Two programs need more than the idea of a connection. They must carry out their actions in an agreed sequence. A useful abstract sequence is: create a socket, connect the programs, send data according to the protocol, receive the expected data, and close the connection when communication is complete. The protocol determines which program sends or reads at each communication point; the socket provides the two-way path used for those exchanges.
Tracing a Planned Exchange
Program A needs to exchange data with Program B without leaving either program waiting indefinitely.
- 1Create
The programs establish the socket-based communication setup.
- 2Connect
The programs use the socket as their two-way connection.
- 3Send
The program identified by the protocol sends first, rather than both programs immediately trying to read.
- 4Receive
The other program reads the available data and follows the protocol's rule for its response.
- 5Close
After the planned exchange is complete, the connection is closed.
The socket supplies the communication path, while the protocol supplies the order that tells the programs when to send and when to receive.
Socket and File Compared
| Feature | File | Socket |
|---|---|---|
| What it connects to | Local stored data | Another program |
| Reading | Reads local data | Can wait for the other program to send data |
| Writing | Writes local data | Sends data through a two-way connection |
| Communication order | Does not describe a two-program conversation | Requires protocol rules for orderly exchange |
A socket resembles a file through its reading and writing operations, but it connects programs rather than providing local storage.
Mistakes That Cause Stalls
Common mistake Treating a socket as if it were only local storage
What it looks likeAssuming that a read always finds data immediately, as it might when thinking only about stored file contents.
Why it failsA socket reads from another program. If that program has not sent data, the read can block and wait.
Do this insteadAccount for the other program's actions and follow the communication protocol.
Common mistake Having both programs read first
What it looks likeProgram A waits for Program B, while Program B waits for Program A.
Why it failsNeither program sends the data that would allow the other read to proceed.
Do this insteadUse protocol rules that identify who sends first and what response follows.
Common mistake Confusing the connection with the protocol
What it looks likeCreating a two-way socket and assuming that the programs automatically know the message order.
Why it failsThe socket provides the path for reading and writing, while the protocol defines the precise communication sequence.
Do this insteadDescribe both the socket connection and the rules governing the exchange.
When analyzing a socket conversation, write down the next action for each program. Mark whether it sends or reads, identify the data expected, and check that at least one program sends before the other program must read. This makes a possible waiting cycle visible before it becomes a deadlock.
Check Your Understanding
Two programs are connected by a socket. The protocol says that Program A sends first, Program B reads and sends a response, and Program A reads the response. Explain why this order is less likely to produce the simultaneous waiting problem than an order in which both programs read first.
Hints
- Identify which program performs the first send.
- Ask what Program B can read after Program A sends.
- Compare this with the situation where neither program sends.
Describe the difference between a file and a socket in two parts: first explain what each one connects a program to, then explain why a socket read can wait.
Hints
- A file is associated with local stored data.
- A socket connects two programs.
- A socket read waits when no data is available.
Key Takeaways
- A socket is a two-way connection that lets two programs read and write data.
- A file is associated with local stored data, while a socket connects a program to another program.
- Reading from a socket when no data is available can block the reading program until the other program sends data.
- If both programs wait to read before either sends, communication can reach a deadlock.
- A protocol prevents this by defining who sends first, what is sent, what response is expected, and who sends next.