WebSocket API Lab - Client-side

Explore & Observe - Questions

Before Opening the Connection

• Open the Console and type:

socket.readyState

1. What number do you see? What does that value represent in the WebSocket lifecycle?

The `readyState` is not available because it's only available when creating the WebSocket object to connect it to the server.

Immediately After Clicking “Open Connection”

• Type again:
  socket.readyState

2. What value do you see now? Which constant does it match (CONNECTING, OPEN, CLOSING, or CLOSED)?

Immediately after opening up the socket I see the readyState switch to a value of `0` which is defined as `CONNECTING`

When the “Status: Connected ✅” Appears

• Check socket.readyState again.

3. What value is displayed? What does that tell you about the connection's ability to send and receive data?

After connecting I see the readyState of the socket switch to `1` which is defined as `OPEN`

While the Connection Is Still Open

• Type several messages using the Send button.

4. Does socket.readyState change during normal message exchange? Why or why not?

No it doesn't change because after opening a socket it remains open unless you get disconnected from the internet. Since, Websockets are designed to keep an open connection--since that's the point of WebSockets

After Clicking “Close Connection”

• Check socket.readyState immediately after you click Close.

5. What value do you see while the connection is shutting down? What value do you see a few seconds later, after it fully closes?

Yes, the value changes. Immediately after pressing the close connection button the value changes from `2`, and then `3`, which is defined as `CLOSING` and `CLOSED` respectively

Reflection Questions

1. How is a WebSocket connection different from an HTTP request? (Think about persistence, who initiates communication, and when the connection closes.)

It's different from an HTTP request because it keeps the connection open and tries to reconnect after getting disconnected (if it wasn't closed intentionally). In a normal HTTP request, the connection is designed to be closed once the client finishes its request and receives a response from the server. In websockets, both the client and server can talk to each other freely.

2. Why are WebSockets ideal for real-time applications such as chats, dashboards, or multiplayer games? (Explain how the connection model supports continuous updates.)

Because the connection can remain open and can be utilized to create realtime applications instead of having to rely on methods such as polling or page refreshes which take more time to do especially on high-latency networks.

3. Why is WebSocket communication considered stateful? (Relate this to how readyState and event handlers maintain ongoing connection context.)

WebSocket communication is considered stateful because the connection maintains persistent context and state information throughout its lifecycle. Unlike stateless HTTP requests where each request is independent, WebSockets preserve connection state through the readyState property and event handlers. The readyState tracks the current connection phase, allowing the application to maintain awareness of the connection's status. And things such as event handlers remain attached allowing you to manage that lifecycle as well.

4. What do the readyState values reveal about the lifecycle of a WebSocket? (How does each state—CONNECTING, OPEN, CLOSING, CLOSED—help a developer manage program logic?)

The readyState is useful because in a production-level application you can check these values whenever you want to determine if the channel is available or not, and you can use it to display/hide different UI elements in your application. It also reveals that a WebSocket connection is a 4-stage process in terms of its entire lifecycle.

5. If two users connect to the same WebSocket server at the same time, how might each user's readyState differ during setup or closing? (Think about concurrency and timing differences between independent client sessions.)

Each user's readyState can differ due to timing variations and network conditions, even when connecting simultaneously. During setup, User A might reach OPEN (1) while User B is still at CONNECTING (0) due to different network latency, for example. During closing, if both users disconnect at the same time, one might transition through CLOSING (2) faster than the other due to different network conditions or client-side processing speeds. Additionally, if the server becomes overloaded, it might accept one connection immediately while queuing the other, causing their readyState timings to be staggered. Each WebSocket connection is independent, so their state transitions occur based on their individual network path and timing, not synchronized with other users.