Why do stream sockets require net/read and net/write while datagram sockets require net/recv-from and net/send-to? #1441
-
|
https://janet-lang.org/docs/networking.html offers no explanation of why. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
|
That's not exactly what it says, but that is more or less conventional. Conceptually, none of this is Janet-specific; it's just how networking works (especially with the BSD sockets API). Stream sockets are always connected to a specific peer, so the source and destination addresses are stored in the stream. Once the connection is established, you can just read and write to the stream, much like a file. Datagram sockets can be bound to an address, but they don't have to be, since each datagram is sent or received independently. In fact, the documentation shows both approaches. On the client side, you're probably only talking to a single server, so it probably makes sense to "connect" to it and read/write. Although this is really just a convenience: you could use send-to/recv-from on the client and specify/verify the server address for every message. On the server side, you're probably interacting with multiple clients, so it probably makes sense to just receive datagrams from any address and send them to any address on a case-by-case basis. Ultimately, it depends on the situation. The client/server distinction might not be clear for all applications, so this is just a starting point. |
Beta Was this translation helpful? Give feedback.
-
|
I'm still a little confused. |
Beta Was this translation helpful? Give feedback.
-
|
If you're new to networking, Janet's documentation probably isn't the best place to start. I would look for a general tutorial on networking first. Briefly, a stream socket is like a telephone call: you make a connection, both sides know who they're talking to, and you can just talk back and forth until you're done. Datagrams are more like putting postcards in the mail: you have to put the destination and return address on each one individually. Also, at least in the case of UDP, there's no guarantee that it will arrive. Most everyday networking, such as https, is all streams. Datagrams are more niche; if you're not sure what they are, you can probably ignore them until later. |
Beta Was this translation helpful? Give feedback.
-
|
The classic: https://beej.us/guide/bgnet/ |
Beta Was this translation helpful? Give feedback.
-
|
It seems a datagram server cannot pretend that it has a persistent connection, but a datagram client can. |
Beta Was this translation helpful? Give feedback.
-
|
More or less. With UDP in particular (local UNIX-domain datagrams can be a bit different), messages come in one by one, from any source, in any order. And some of them get lost on the way. Your application can certainly try to pretend that it has persistent connections, but the networking API isn't really going to help you with that. It's technically the same for the client, it just tends to be easier to pretend you have a connection when you're only exchanging messages with one other host. An interesting example here is a stateful firewall (such as the one you presumably have on your home router). A typical firewall will allow outgoing traffic, plus incoming traffic that is sent in response. For TCP, this is straightforward because it's clear when packets belong to an established connection. For UDP, the firewall has to fake it. It has some rules that help it guess whether an incoming UDP packet can be considered a response to a previous outgoing one, constituting a kind of virtual connection. So an application can always pretend that a sequence of datagrams constitute a connection, but it's up to each application to decide what that means. As far as Internet traffic goes, it's important to note that at a certain low level, TCP (streams) and UDP (datagrams) look very similar. The difference is that TCP is doing a bunch of work behind the scenes to turn a chaotic storm of individual packets into something that looks like a reliable stream of data, making it easier to work with. UDP applications often end up reimplementing at least some of the work that TCP would have done for them. The main reason to use UDP is when you need performance above all else and you only need some subset of the features of TCP, which you're willing to implement yourself. Not that many applications actually benefit from taking on that burden. |
Beta Was this translation helpful? Give feedback.
-
|
Can a datagram client use |
Beta Was this translation helpful? Give feedback.
If you're new to networking, Janet's documentation probably isn't the best place to start. I would look for a general tutorial on networking first.
Briefly, a stream socket is like a telephone call: you make a connection, both sides know who they're talking to, and you can just talk back and forth until you're done. Datagrams are more like putting postcards in the mail: you have to put the destination and return address on each one individually. Also, at least in the case of UDP, there's no guarantee that it will arrive.
Most everyday networking, such as https, is all streams. Datagrams are more niche; if you're not sure what they are, you can probably ignore them until later.