Really appreciated how you explained web sockets in comparison with HTTP Requests, making the exact point of utilizing web sockets stand out. That really helped me understand much better🙌
Really appreciate the video. The animations made it so much easier to follow along and I completely understood it with a single watch. Keep up the great work.
It is so easy to study for my system design interviews when I have so much quality youtube to click through, quite lazily I might add. Thanks for the amazing videos!
Quite good video, but one thing with long polling is that the server did not necessarily have to end the request to send data, by writing to the response and then triggering a flush, the written parts got sent to the client and the get request stayed open so the client only had to re connect once it timed out, and if the server kept sending something, the browser kept waiting. This might not work with modern ajax type requests but we used an even older solution where you added a script tag for a js file, I think that later got the name jsonp. The browser will parse and process that js file as data comes through so the server send js commands that when executed triggered a reaction, and if the server had nothing to send it sent a command that did nothing. This still tied up resources of cause, but this was before ajax was a thing so it was this method or using a java applet, flash object or similar if you wanted any type of polling.
Hi there. Thank you for sharing such a well-presented and easy to understand explanation. Can I ask for your permission to remake this video and translate it into Vietnamese to share with my audiences on TH-cam? Most of them are IT students and of course it is non-commercial purpose. Thank you!
This was made from system design interview perspective. I have done a part-2 follow up video to deep dive on web sockets , please check that out in my channel
But you haven't explained *how* it works. Not even a bit. Like what is behind those well-known WS interfaces? What is in the TCP package? Is it any special for WS? Do we need a URL to establish a connection? How to distinguish one connection from another one? Is there a notion of a cookie? How does the session work in the context of WS-based service? How does load balancing work with WS connections? What is the usual limit on the number of WS connections? Is it a number of opened file descriptors? What it depends on?
Thanks for the feedback with specific examples. While these are good question, this video was made for System Design Interviews. To our knowledge, this level of detailing on web-sockets is not required in any of the Tier1/Tier2 Tech companies from System Design perspective, unless one is applying for a speciality position. Based on my market research, I may plan to deep dive on websockets in future. Thanks again!
It was a nice video, but it barely explained "How Web Sockets work", only in 3:45 to 4:18. Almost all of the video was actually about "What are Web Sockets", focusing mainly on a comparison between polling and sockets, which was well presented, but wasn't supposed to be the topic of the video promised by the title.
WS is like an additional layer of protocol on top of http/s, however browser supports client server due to security reasons so how the socket able to send request from the server to the client?
When you cannot directly track WebSocket payload acknowledgments using the same WebSocket connection, you can implement a custom acknowledgment mechanism using a combination of techniques. 1. Create a Unique Identifier for Each Payload: Before sending a payload from the frontend, assign a unique identifier (message ID) to each payload. This ID will help you correlate the acknowledgments received from the backend with the original payloads sent from the frontend. 2. Use a Separate Channel for Acknowledgments: Set up a separate communication channel between the frontend and backend. This can be another WebSocket connection, an HTTP REST API, or any other messaging protocol that suits your application. 3. Send Payloads and Wait for Acknowledgments: When sending a payload from the frontend to the backend via the primary WebSocket connection, store the payload's unique identifier along with its content in a local data structure (e.g., a map). 4. Backend Processing and Acknowledgment: On the backend, process the received payload and perform the required actions. After the backend has processed the payload successfully, it sends an acknowledgment message back to the frontend via the separate communication channel, containing the unique identifier of the processed payload. 5. Frontend Acknowledgment Handling: When the frontend receives an acknowledgment, it can use the unique identifier in the acknowledgment message to identify the corresponding payload in the local data structure and mark it as acknowledged. You can remove the entry or update its status in the map.
I stopped watching when author said that for polling you need to open connections for each request. Http 1.1 support keep-alive header to keep connection open. So you use the same connection to make requests.
Yes, HTTP/1.1 supports the Keep-Alive header, allowing the reuse of a single connection for multiple requests. Thanks for pointing that out! What I meant to highlight is that in polling, even though the connection can be kept open, the client still has to send repeated requests at regular intervals to check for updates. This can lead to inefficiencies in terms of bandwidth and server load, especially when there’s no new data. Alternatives like long polling and WebSockets can be more efficient for real-time updates, as they reduce the need for frequent requests or allow continuous, bidirectional communication. I have made a deep-dive video on Web Sockets in the description.
WebSockets use TCP, not UDP because TCP provides reliable, ordered, and error-checked communication, which is crucial for WebSocket connections. UDP is used in scenarios where speed is more important than reliability, and some data loss is acceptable, for instance Video streaming (e.g., live broadcasts), Online gaming, Voice over IP (VoIP), video calls and IoT devices , all these are stateless. So, WebSockets excel in real-time, full-duplex communication with reliable data delivery, ideal for chat apps, stock updates, and collaborative tools. For lightweight, low-latency, or stateless tasks, protocols like UDP and RTP are more efficient due to lower overhead.
This is web sockets from System Design interview perspective, where you are only expected to know about websockets at a high level. Based on previous request I have also made a part-2 deep dive video in my pinned comment below. Thanks.
Part-2: Web Sockets Deep Dive
th-cam.com/video/G0_e02DdH7I/w-d-xo.html
Glad to know you accepted feedback and posted a new video ❤
Really appreciated how you explained web sockets in comparison with HTTP Requests, making the exact point of utilizing web sockets stand out. That really helped me understand much better🙌
Thanks for taking the time to comment on the video. Soon I will be publishing an advance tutorial on Web Sockets, so stay tuned :)
Really appreciate the video. The animations made it so much easier to follow along and I completely understood it with a single watch. Keep up the great work.
It is so easy to study for my system design interviews when I have so much quality youtube to click through, quite lazily I might add. Thanks for the amazing videos!
I could listen to you say "full duplex asynchronous messaging" all day.
Great Video! For the impatient ones, jump directly to 03:20 to know about websockets!
I learnt this is computer communication lecture many years ago. Glad to have a refresher now!
I like how 90% of this video has NOTHING to do with Websockets 😂
Great video.
Incredible efforts! to be honest i am truly grateful to find this channel ! keep up the good work! thank you so much
thank you for the comment, keeps me going :)
As others have said, this is some of the best content on TH-cam. Could you do a complete course on K8S? I’d happily pay for it
Amazing content. I hope You Reach Millions of subscribers
It took 200 mins to watch but everything explained really well
Did you mean with repeats?
You mean seconds?
Crystal clear explanation
This is very clear and easy to understand.
Thanks!
Love this .. explanation, use cases, when not use every thing was covered 10/10
Very nice bhai...
This is A-tier content. Keep up the good work!
Really well represented, thanks for sharing
Amazing simple explanation, subscribed :)
awesome explanation, thank you
That was awesome explanation.
appreciate your work thanks a ton
Quite good video, but one thing with long polling is that the server did not necessarily have to end the request to send data, by writing to the response and then triggering a flush, the written parts got sent to the client and the get request stayed open so the client only had to re connect once it timed out, and if the server kept sending something, the browser kept waiting.
This might not work with modern ajax type requests but we used an even older solution where you added a script tag for a js file, I think that later got the name jsonp.
The browser will parse and process that js file as data comes through so the server send js commands that when executed triggered a reaction, and if the server had nothing to send it sent a command that did nothing.
This still tied up resources of cause, but this was before ajax was a thing so it was this method or using a java applet, flash object or similar if you wanted any type of polling.
Nice video, Thank you!
So clear & well described 👌
cool, very simple explanation 👍
Hi there. Thank you for sharing such a well-presented and easy to understand explanation. Can I ask for your permission to remake this video and translate it into Vietnamese to share with my audiences on TH-cam? Most of them are IT students and of course it is non-commercial purpose. Thank you!
Title should have benn HTTP polling 😂
This was made from system design interview perspective. I have done a part-2 follow up video to deep dive on web sockets , please check that out in my channel
Loved this!
excellent👍
Excellent video.
Amazing 👌
Wonderful explanation ❤
Thanks! Really useful
gold content. thank you!!
But you haven't explained *how* it works. Not even a bit. Like what is behind those well-known WS interfaces? What is in the TCP package? Is it any special for WS? Do we need a URL to establish a connection? How to distinguish one connection from another one? Is there a notion of a cookie? How does the session work in the context of WS-based service? How does load balancing work with WS connections? What is the usual limit on the number of WS connections? Is it a number of opened file descriptors? What it depends on?
Thanks for the feedback with specific examples. While these are good question, this video was made for System Design Interviews. To our knowledge, this level of detailing on web-sockets is not required in any of the Tier1/Tier2 Tech companies from System Design perspective, unless one is applying for a speciality position. Based on my market research, I may plan to deep dive on websockets in future. Thanks again!
He means that the title of this videos should not be "How websocket work". It should be "What is websocket".
That's exactly what I was expecting 😅
Nicely explained
thank you!
Nice video!
Amazing content
شكرا thanks
good one!!
Great ! If possible to make a longer video about its usecases, like a small tuto ?
thank you for the suggestion
It was a nice video, but it barely explained "How Web Sockets work", only in 3:45 to 4:18.
Almost all of the video was actually about "What are Web Sockets", focusing mainly on a comparison between polling and sockets, which was well presented, but wasn't supposed to be the topic of the video promised by the title.
it is important to know the motivation for why web socket exists before we learn web sockets. What problem is it solving and why do we need it?
WS is like an additional layer of protocol on top of http/s, however browser supports client server due to security reasons so how the socket able to send request from the server to the client?
please checkout the deep dive video, link in pinned comment/description
thank you brother
Great video. Keep going!
this is gold info
thank you for doing this!!
I will tell everyone about this channel
@@henryl7421 Thank you for supporting my work 🙏, this will keep me going
How do you create animations ?
With the help of Adobe after effects.
What tool u used for animation in the video
I even reported this dude for misinformation 😂
thank you for sharing :D
whats the best way to track websocket payload acknowledgement from frontend? (given we can't do it with the same websocket connection)
When you cannot directly track WebSocket payload acknowledgments using the same WebSocket connection, you can implement a custom acknowledgment mechanism using a combination of techniques.
1. Create a Unique Identifier for Each Payload:
Before sending a payload from the frontend, assign a unique identifier (message ID) to each payload. This ID will help you correlate the acknowledgments received from the backend with the original payloads sent from the frontend.
2. Use a Separate Channel for Acknowledgments:
Set up a separate communication channel between the frontend and backend. This can be another WebSocket connection, an HTTP REST API, or any other messaging protocol that suits your application.
3. Send Payloads and Wait for Acknowledgments:
When sending a payload from the frontend to the backend via the primary WebSocket connection, store the payload's unique identifier along with its content in a local data structure (e.g., a map).
4. Backend Processing and Acknowledgment:
On the backend, process the received payload and perform the required actions. After the backend has processed the payload successfully, it sends an acknowledgment message back to the frontend via the separate communication channel, containing the unique identifier of the processed payload.
5. Frontend Acknowledgment Handling:
When the frontend receives an acknowledgment, it can use the unique identifier in the acknowledgment message to identify the corresponding payload in the local data structure and mark it as acknowledged. You can remove the entry or update its status in the map.
Almost all apps nowadays have Real Time part in them
U misrepresented a normal request. The response is in the same connection, not a new one as there is no way for the server to contact the client.
I stopped watching when author said that for polling you need to open connections for each request. Http 1.1 support keep-alive header to keep connection open. So you use the same connection to make requests.
Yes, HTTP/1.1 supports the Keep-Alive header, allowing the reuse of a single connection for multiple requests.
Thanks for pointing that out! What I meant to highlight is that in polling, even though the connection can be kept open, the client still has to send repeated requests at regular intervals to check for updates. This can lead to inefficiencies in terms of bandwidth and server load, especially when there’s no new data.
Alternatives like long polling and WebSockets can be more efficient for real-time updates, as they reduce the need for frequent requests or allow continuous, bidirectional communication.
I have made a deep-dive video on Web Sockets in the description.
nicely explained
Nice thanks bro
thank you
Great great
thanks
Great
Wait web sockets use TCP? But I thought UDP was the fast one. Then who the the hell DOES use UDP?
WebSockets use TCP, not UDP because TCP provides reliable, ordered, and error-checked communication, which is crucial for WebSocket connections. UDP is used in scenarios where speed is more important than reliability, and some data loss is acceptable, for instance Video streaming (e.g., live broadcasts), Online gaming, Voice over IP (VoIP), video calls and IoT devices , all these are stateless.
So, WebSockets excel in real-time, full-duplex communication with reliable data delivery, ideal for chat apps, stock updates, and collaborative tools. For lightweight, low-latency, or stateless tasks, protocols like UDP and RTP are more efficient due to lower overhead.
@@ByteMonkBut in your video you said that for gaming we use web web sockets
I use WebSocket to get real cryptocurrency data
Who asked you about polling
No One :)
Crisp
Das Video erklärt viel Kontext, aber leider keine Details zu WebSockets. Schade
1st
If I wanted to know about HTTP, I would have studied it somewhere else. This is a completely misleading title.
This is web sockets from System Design interview perspective, where you are only expected to know about websockets at a high level. Based on previous request I have also made a part-2 deep dive video in my pinned comment below. Thanks.
speaking too fast bro
thanks for the feedback, will work on my pace
You won a subscriber from Afghanistan.
Great Video.