Technically, it’s not so much networking (though parts of it are) as development of webservices and -applications.
Most of the stuff you do with these tools happens in the application (the actual information of the question and answer) and some in the presentation (how the question and answer are phrased), where you don’t generally worry about the actual transport of your question across the network.
Basically, if you’re asking someone for the time, “what’s the time?” would be the application data, while the presentation would be “hour and minute in 24h format” (or some shorthand for that).
The actual network part would be how you figure out who to ask, how you open the conversation (“Excuse me,”) or how you transmit the question (speech, text message, written letter) in the first place, but if we’re talking about asking for the time, we usually just take those communication basics for granted.
If you would like me to, I could try to explain more about the various options and parts of these requests (“questions”) in low-tech terms. I don’t think you need extensive knowledge about networking or software development to grasp the basics, if you’re interested (and I manage to translate it well enough).
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 @luciferofastora@feddit.org, 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.
haaa ! oh, that’s nice. Great didactics. I guess I never had any idea of how things networking might be compartmentalized. Appreciate the example with Lemmy. I am tempted to ask more (could you actually send this comment via curl? how would you attach the authentification token? is there a builtin way to do such a thing or would it require abusing the command in some way? etc.) but there’s a point where it makes more sense for me to take a class, haha. Having just switched my work machine to Linux, I learn a bit more everyday about things that used to be hidden from me, but suddenly come with the territory, so to say. Really enjoyed this overview, thanks again for indulging me
Technically, it’s not so much networking (though parts of it are) as development of webservices and -applications.
Most of the stuff you do with these tools happens in the application (the actual information of the question and answer) and some in the presentation (how the question and answer are phrased), where you don’t generally worry about the actual transport of your question across the network.
Basically, if you’re asking someone for the time, “what’s the time?” would be the application data, while the presentation would be “hour and minute in 24h format” (or some shorthand for that).
The actual network part would be how you figure out who to ask, how you open the conversation (“Excuse me,”) or how you transmit the question (speech, text message, written letter) in the first place, but if we’re talking about asking for the time, we usually just take those communication basics for granted.
If you would like me to, I could try to explain more about the various options and parts of these requests (“questions”) in low-tech terms. I don’t think you need extensive knowledge about networking or software development to grasp the basics, if you’re interested (and I manage to translate it well enough).
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 @luciferofastora@feddit.org, 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.
haaa ! oh, that’s nice. Great didactics. I guess I never had any idea of how things networking might be compartmentalized. Appreciate the example with Lemmy. I am tempted to ask more (could you actually send this comment via curl? how would you attach the authentification token? is there a builtin way to do such a thing or would it require abusing the command in some way? etc.) but there’s a point where it makes more sense for me to take a class, haha. Having just switched my work machine to Linux, I learn a bit more everyday about things that used to be hidden from me, but suddenly come with the territory, so to say. Really enjoyed this overview, thanks again for indulging me