Sep-13-2017, 10:01 PM
The internet (and networking) is a bunch of layers of interfaces and apis, each making the next layer slightly easier to work with. A socket is one of the lowest levels there are.
It's kind of like building materials. You can go buy a door... or you can go to a lower level, and buy some wood, some screws, and a couple hinges, and make your own door. A socket is like the screw in this example. Most people will just skip it, and use something that's built on top of it. But if you're learning what they are, it can be neat to see how they work.
Your network interface (some computers have more than one) has an ip address. That's how other computers can contact you. An ip address is a lot like a house's address. The network interface also has ports. Those are lines of communication that connect programs on the computer, to the outside world. In the house example, a port would be something like a window or a door. A single network interface has many, many ports (more than 10,000).
A socket is how a program claims a port for itself, so no other program can use that port. The process of claiming a port is called "binding". But that just lets a program listen... other programs need to know which port to try to use to contact your program. This is called a server.
A different program can open a socket to that same port, for sending. That's called a client. Once a client connects with a server over a port, they can begin sending information back and forth to each other. Either the client, or the server, can close the connection, which is called "breaking the socket".
"endpoint instance" is just another phrase for describing which port you're listening to.
Really, though, you probably don't want to use sockets. TCP (how webpages work) is very verbose at the socket level. And by verbose, I mean there's a lot of communication back and forth
"Helo server!"
"eloh client!"
"I'd like page xxx/xxx/xxx.html please"
"sure thing, pal! it's 2492 bytes long"
"2492 bytes, ok, i'm ready and waiting to start downloading"
"cool, here it comes! *sends 256 bytes*"
"I just sent 256 bytes, did you get them?"
"I sure did! Keep sending the rest!"
"ok, here it comes! *sends 512 bytes*"
"I just sent 512 bytes, did you get them?"
"no, I didn't. Please try again"
on and on and on. Using a networking library on top of that makes things so much easier.
...and don't dig too deeply into it. You might become terrified about how the giant bowl of spaghetti we call the internet is barely held together by yarn, and it's continuing functionality at acceptable speeds is incredibly amazing.
It's kind of like building materials. You can go buy a door... or you can go to a lower level, and buy some wood, some screws, and a couple hinges, and make your own door. A socket is like the screw in this example. Most people will just skip it, and use something that's built on top of it. But if you're learning what they are, it can be neat to see how they work.
Your network interface (some computers have more than one) has an ip address. That's how other computers can contact you. An ip address is a lot like a house's address. The network interface also has ports. Those are lines of communication that connect programs on the computer, to the outside world. In the house example, a port would be something like a window or a door. A single network interface has many, many ports (more than 10,000).
A socket is how a program claims a port for itself, so no other program can use that port. The process of claiming a port is called "binding". But that just lets a program listen... other programs need to know which port to try to use to contact your program. This is called a server.
A different program can open a socket to that same port, for sending. That's called a client. Once a client connects with a server over a port, they can begin sending information back and forth to each other. Either the client, or the server, can close the connection, which is called "breaking the socket".
"endpoint instance" is just another phrase for describing which port you're listening to.
Really, though, you probably don't want to use sockets. TCP (how webpages work) is very verbose at the socket level. And by verbose, I mean there's a lot of communication back and forth
"Helo server!"
"eloh client!"
"I'd like page xxx/xxx/xxx.html please"
"sure thing, pal! it's 2492 bytes long"
"2492 bytes, ok, i'm ready and waiting to start downloading"
"cool, here it comes! *sends 256 bytes*"
"I just sent 256 bytes, did you get them?"
"I sure did! Keep sending the rest!"
"ok, here it comes! *sends 512 bytes*"
"I just sent 512 bytes, did you get them?"
"no, I didn't. Please try again"
on and on and on. Using a networking library on top of that makes things so much easier.
...and don't dig too deeply into it. You might become terrified about how the giant bowl of spaghetti we call the internet is barely held together by yarn, and it's continuing functionality at acceptable speeds is incredibly amazing.