ah ok, yeah, thanks for reframing. I’m not sure if the natural language approach is best, but that might just be me, I never resonated too well with this kind of high level analogies. I do appreciate the effort though. I didn’t realize this had to do with web development exactly. So the networking part is abstracted away ?
I’m not sure if the natural language approach is best, but that might just be me, I never resonated too well with this kind of high level analogies.
Without knowing your level of technical background, I defaulted to the same kind of analogy I use with family. If that isn’t the best approach for you, I’m happy to try a different angle.
So the networking part is abstracted away ?
Yes, mostly.
For a brief excursion, the rough gist of networking is that the world wide web is just a bunch of connected computers, which is where the web analogy is from. To get a message to a specific computer, you first have some links that get your data packets from one node to the next. Then you have a routing protocol that figures out which node to send to next (IP being the most common one).
Then you have a transport protocol that prepares the packets to send on one end, reassembles the full message on the other if it had to be split up into multiple packets and checks that the contents look intact. In the case of TCP, it also establishes a connection to verify that all packets actually have arrived. In the case of UDP, it’s more like that online retailer that sent my parcel without tracking and didn’t care when it disappeared. Still mad about that. Anyway.
Transport doesn’t care how routing works. A computer directly connected to yours is no better than one halfway across the world, aside from being faster to reach. Likewise, routing doesn’t care how the packets get across. Whether by WiFi, optic fiber or SD card strapped to a homing pigeon – so long as the next node gets the packet, the job is done.
There are cases in web development where you do care about the transport protocol, but for making HTTP requests like you do with curl, you generally use a standard set of protocols (TCP/IP) and trust the network stack to get your messages there and back again. All you need is the address or the name (in which case, again, you trust the network to figure it out) and the actually relevant application info.
For this comment, my app knows the lemmy server to send to and the authentication token it uses to prove I’m actually @[email protected], so it bundles the ID of the parent comment I’m responding to and the body of my message up into a request, adds that authentication token and sends it to the server. How it gets there? Not Voyager’s business.
If I had a token, the exact recipient address and whatever metadata it requires, I could probably send the comment via curl too.
ah ok, yeah, thanks for reframing. I’m not sure if the natural language approach is best, but that might just be me, I never resonated too well with this kind of high level analogies. I do appreciate the effort though. I didn’t realize this had to do with web development exactly. So the networking part is abstracted away ?
Without knowing your level of technical background, I defaulted to the same kind of analogy I use with family. If that isn’t the best approach for you, I’m happy to try a different angle.
Yes, mostly.
For a brief excursion, the rough gist of networking is that the world wide web is just a bunch of connected computers, which is where the web analogy is from. To get a message to a specific computer, you first have some links that get your data packets from one node to the next. Then you have a routing protocol that figures out which node to send to next (IP being the most common one).
Then you have a transport protocol that prepares the packets to send on one end, reassembles the full message on the other if it had to be split up into multiple packets and checks that the contents look intact. In the case of TCP, it also establishes a connection to verify that all packets actually have arrived. In the case of UDP, it’s more like that online retailer that sent my parcel without tracking and didn’t care when it disappeared. Still mad about that. Anyway.
Transport doesn’t care how routing works. A computer directly connected to yours is no better than one halfway across the world, aside from being faster to reach. Likewise, routing doesn’t care how the packets get across. Whether by WiFi, optic fiber or SD card strapped to a homing pigeon – so long as the next node gets the packet, the job is done.
There are cases in web development where you do care about the transport protocol, but for making HTTP requests like you do with curl, you generally use a standard set of protocols (TCP/IP) and trust the network stack to get your messages there and back again. All you need is the address or the name (in which case, again, you trust the network to figure it out) and the actually relevant application info.
For this comment, my app knows the lemmy server to send to and the authentication token it uses to prove I’m actually @[email protected], so it bundles the ID of the parent comment I’m responding to and the body of my message up into a request, adds that authentication token and sends it to the server. How it gets there? Not Voyager’s business.
If I had a token, the exact recipient address and whatever metadata it requires, I could probably send the comment via curl too.