For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Renan Ferro -
Ayush Sharma -
Rahil Vahora -
Elizabeth Sobiya -
Top comments (19)
You have a agreement with your best friend that she'll help with your math homework when you're stuck.
When you have a question, you call her, wait for her to answer, then ask your question, and listen while she replies. Then she hangs up and you carry on with your homework.
Most evenings, you call her a few times over the course of an hour or so. Sometimes she's too busy to answer, so you hang up, twiddle your thumbs and try in a few minutes.
But some evenings, homework is too hard, and you're practically calling her every five minutes. Although she doesn't mind helping you, neither of you are happy about the constant process of dialling her, waiting for her to answer, and hanging up, only to do the same thing a few minutes later.
Finally you settle upon a sane solution. You call her, and keep the line open. There's silence while you're working on your own, but when you have a question, you just have to start speaking and she can already hear you. When your homework is over, you can hang up for the evening.
Your friend is the server, you're the browser app, the call is a network connection and keeping the line open after calling is a websocket connection.
Well done (including the responders)!
As a junior dev, there's a ton of buzzwords out there that seem to live right at the very edge of understanding. Like... I've always had a somewhat vague concept of what a web socket would need to do to be called a web socket (and suddenly I'm talking like I'm five!)... but would not be able to accurately describe web sockets using complete sentences (and I'm finding that hand gestures and facial expressions aren't much help, either).
This gives me a solid 'metaphor' framed in something nice and concrete and warm that I'm better able to retain. Being a very visual person, I can admit to having struggles early on trying to 'visualize' some of the abstractions I needed to work with, simply because I couldn't 'see' the data structure (electrical/mechanical background) involved.
Our Lead/Architect (and a great mentor) used to go above and beyond with me (I carried a small whiteboard to his desk, sneaker-net style)... taking time to draw out the tougher bits.
I'm LOVIN' this "Five Year old" series!
You have a friend, that always has the newest gossip. Because you want to stay up to date, you ask him every 15 minutes, if he has something new. But most of the time he does not have any news and sometimes several things happenend in the last few minutes.
So you and your friend agree that you will call him and leave the line open. Once your friend has news, he will tell them to you immediatly.
Perfect!
No WebSockets
With WebSockets
One day, some clever people were looking at a river, and wondered how they could get some water back to their house. So they decided that they would use buckets.
Everyone thought that buckets where great. They could send robots with buckets down to the river anytime they wanted, and they'd get buckets full of water back. It didn't matter which robots, or which buckets, the water was always the same.
But one day, the clever people started to think about how difficult it was when they only wanted a glass of water every now and then, or when they wanted to have a bath. Because it was all just buckets, you either had loads of water, or else you had to have loads of buckets. It was only good if you actually wanted a bucket of water.
And so the clever people thought again. And now, instead of the robots carrying buckets down to the river, every now and then they'd carry a hose instead. Now a hose couldn't be reused by everyone, like the buckets, but it did mean you could just run it anytime you wanted a glass of water, or leave it running for ages if you wanted to fill a bath.
The river is a website. The house is a browser. The buckets are HTTP requests and responses. The water is data, of course. The hoses are websockets. The clever people in the house are the HyBi Working Group of the IETF, and I'm only saying they're clever because I was one of them. The robots are just robots. Because robots are cool.
You know how you like to leave the faucet running in the bathroom? It's sort of like that.
Sorry, did you mean my five year old, specifically?
That sounds like a great idea. Why wouldn't I always leave the faucet running?
Eventually, the sink overflows. It seems like a great idea at first, but leaving it open is just wasteful.
Here's my try at it. I'm not a native english speaker, so I hope you'll forgive my mistakes. Also it's not meant to be technically accurate --
You want to know about Websockets ?
Ok, but first I have to explain Internet to you. Internet is like a bunch of tunnels, connecting all the computers and phones and stuff. In these tunnels, there's a lot of things, like pipes that we call UDP. And then there's this very neat conveyor belts we call TCP. They never lose anything, and everything arrives in the order it was sent, unlike the pipes. Also, they are 2-ways, that's very handy. Plenty of great uses : many many apps send and get packages with TCP.
There's a bunch of apps for example, like Firefox and Chrome, they all send similar packages with TCP : same label on the packages, no fancy post-stamps or whatever. This standard way to make the labels is called HTTP. There are other ways, but HTTP is widely used. (HTTP also has a variant with a padlock, it's called HTTPS :) ).
A small example that may ring a bell : among the uses of HTTP, there's this stuff called WWW. They are the websites you know. WWW it a way to organize the contents of the packages, like bubble-wrap, and labels on the goods.
Anyway, back to the HTTP labels.
Some people don't want every kind of package to come and go inside they computers or phones, because bad people could sent them packages filled with smelly cheese, or spiders or gross stuff. So they build Firewalls. For example, you can have a firewall that will burn to ashes any package on the conveyor belt, unless they have a regular HTTP label on them. That way, they feel safer.
The thing is, so many people have started to use these HTTP firewalls nowadays. And anyone sending a package wants to have this nice HTTP label on it, for fear of it being burned. But people really liked the conveyor belt too, because you could send anything through it.
So someone had an idea : What if we send a very very very long package on the conveyor belt. As long as the tunnel itself ! Long enough to go from one computer to another ! And with a nice looking HTTP label on it so the Firewalls won't burn it ! And when the computer who's receiving gets the first end of the package, it can unwrap just the end of it. And guess what's inside ? Another conveyor belt !!!! The computer who's sending still has the rear end of the package, because it's sooo very long. Both computers have kind of cheated the firewall, because now they have their very own conveyor belt and they can send anything they want inside something that looks like an HTTP package. And it's nice because it's also a 2-way conveyor belt. We call these very very long packages "Websockets".
Yes, it's a bit weird. And you're right to ask "Why don't we ask people to ease up on the Firewalls, and use the TCP conveyor belt instead ?". Maybe things could have gone a different way, but this is how it is today, so we have to deal with it. And there is another risk. Maybe people will start using better Firewalls, that can X-Ray the packages, and if they see a conveyor belt in it, they will look at the stuff that it carries, and burn it if they don't like it. But then people could also send very very long packages on the conveyor belt that's inside the HTTP package, and it could go on like that forever.
I, for one, hope it won't.
:)
Usually on the web, you ask someone (googles servers) for something (googles webpage).
A websocket lets someone (googles servers) tell you something even if you didn't ask for it (a new gchat message)
Normal web communication: you send letters to Santa Clause, and he responds on Christmas. He can't contact you directly, only as a response to your call (love).
Web communication trough a web socket: you call Santa (or video call) and you can talk with him as long as the channel is open.
You = client like a browser
Santa = the server
Two people go to meet each other, they have a handshake to say hello, if they like each other they start exchanging information. If they don't like each other they go to separate McDonalds.
Ahhh another Brit (or possibly Canadian).
British :)
This is more like a network request than a web-socket.
Not quite answering the question, but it just hit me that Web Sockets would be an adorable kids program about spider sock puppets.
Websockets let your computer and the website's computer have a conversation just like you do with grandpa over skype.
Let somebody explain HTTP headers and TCP and optionally SSL to you like you're five, and them mix them all together.