Date: Wed, 28 Apr 2021 16:03:11 GMT From: Marc Fonvieille <blackend@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: a1aad57d6d - main - en/books/developers-handbook/sockets/: Fix figures caption. Message-ID: <202104281603.13SG3BC3083829@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=a1aad57d6d7e30681c64e9925323472ed4134a0e commit a1aad57d6d7e30681c64e9925323472ed4134a0e Author: Marc Fonvieille <blackend@FreeBSD.org> AuthorDate: 2021-04-28 16:01:27 +0000 Commit: Marc Fonvieille <blackend@FreeBSD.org> CommitDate: 2021-04-28 16:01:27 +0000 en/books/developers-handbook/sockets/: Fix figures caption. --- .../books/developers-handbook/sockets/_index.adoc | 33 ++++++++++++++-------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/documentation/content/en/books/developers-handbook/sockets/_index.adoc b/documentation/content/en/books/developers-handbook/sockets/_index.adoc index bea670b3d2..a224743a18 100644 --- a/documentation/content/en/books/developers-handbook/sockets/_index.adoc +++ b/documentation/content/en/books/developers-handbook/sockets/_index.adoc @@ -65,7 +65,8 @@ As the languages used in data communications are so terse, we usually refer to t As data travels from one computer to another, it always uses more than one protocol. These protocols are _layered_. The data can be compared to the inside of an onion: You have to peel off several layers of "skin" to get to the data. This is best illustrated with a picture: -image::layers.png[Protocol Layers] +.Protocol Layers +image::layers.png[] In this example, we are trying to get an image from a web page we are connected to via an Ethernet. @@ -117,7 +118,8 @@ Once you have received the data, it is up to you to figure out what to do with i To use an analogy, all the internetworking protocols become a gray area: Not so much because we do not understand how it works, but because we are no longer concerned about it. The sockets interface takes care of this gray area for us: -image::slayers.png[Sockets Covered Protocol Layers] +.Sockets Covered Protocol Layers +image::slayers.png[] We only need to understand any protocols that tell us how to _interpret the data_, not how to _receive_ it from another process, nor how to _send_ it to another process. @@ -272,13 +274,15 @@ struct sockaddr_in { We can visualize its organization this way: -image::sain.png[sockaddr_in] +.sockaddr_in structure +image::sain.png[] The three important fields are `sin_family`, which is byte 1 of the structure, `sin_port`, a 16-bit value found in bytes 2 and 3, and `sin_addr`, a 32-bit integer representation of the IP address, stored in bytes 4-7. Now, let us try to fill it out. Let us assume we are trying to write a client for the _daytime_ protocol, which simply states that its server will write a text string representing the current date and time to port 13. We want to use TCP/IP, so we need to specify `AF_INET` in the address family field. `AF_INET` is defined as `2`. Let us use the IP address of `192.43.244.18`, which is the time server of US federal government (`time.nist.gov`). -image::sainfill.png[Specific example of sockaddr_in] +.Specific example of sockaddr_in +image::sainfill.png[] By the way the `sin_addr` field is declared as being of the `struct in_addr` type, which is defined in [.filename]#netinet/in.h#: @@ -311,11 +315,13 @@ What would the result look like? Well, that depends, of course. On a Pentium(R), or other x86, based computer, it would look like this: -image::sainlsb.png[sockaddr_in on an Intel system] +.sockaddr_in on an Intel system +image::sainlsb.png[] On a different system, it might look like this: -image::sainmsb.png[sockaddr_in on an MSB system] +.sockaddr_in on an MSB system +image::sainmsb.png[] And on a PDP it might look different yet. But the above two are the most common ways in use today. @@ -345,11 +351,13 @@ There is a convention of sending the multi-byte data over IP _MSB first_. This, Now, if we compiled the above code for an Intel based computer, our _host byte order_ would produce: -image::sainlsb.png[Host byte order on an Intel system] +.Host byte order on an Intel system +image::sainlsb.png[] But the _network byte order_ requires that we store the data MSB first: -image::sainmsb.png[Network byte order] +.Network byte order +image::sainmsb.png[] Unfortunately, our _host order_ is the exact opposite of the _network order_. @@ -488,7 +496,8 @@ Beside specifying the port in `addr`, the server may include its IP address. How Suppose we were writing a server for the _daytime_ protocol over TCP/IP. Recall that it uses port 13. Our `sockaddr_in` structure would look like this: -image::sainserv.png[Example Server sockaddr_in] +.Example Server sockaddr_in +image::sainserv.png[] [[sockets-listen]] ===== `listen` @@ -648,7 +657,8 @@ Finally, the daemon starts an endless loop, which performs the following steps: We can _generalize_ this, and use it as a model for many other servers: -image::serv.png[Sequential Server] +.Sequential Server +image::serv.png[] This flowchart is good for _sequential servers_, i.e., servers that can serve one client at a time, just as we were able to with our _daytime_ server. This is only possible whenever there is no real "conversation" going on between the client and the server: As soon as the server detects a connection to the client, it sends out some data and closes the connection. The entire operation may take nanoseconds, and it is finished. @@ -867,7 +877,8 @@ Unlike a sequential server, a _concurrent server_ has to be able to serve more t This requires a significant change in our flowchart: -image::serv2.png[Concurrent Server] +.Concurrent Server +image::serv2.png[] We moved the _serve_ from the _daemon process_ to its own _server process_. However, because each child process inherits all open files (and a socket is treated just like a file), the new process inherits not only the _"accepted handle,"_ i.e., the socket returned by the `accept` call, but also the _top socket_, i.e., the one opened by the top process right at the beginning.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202104281603.13SG3BC3083829>