| <sect1 id="connectivity-ppp-network"> |
| |
| <title>The Network Of Computers</title> |
| |
| <para> |
| This section describes how you could distribute server and |
| client computers to create a collaborative network. |
| </para> |
| |
| <sect2 id="connectivity-ppp-policy-network"> |
| <title>One PPP Network Of Two Computers</title> |
| |
| <para> |
| The simpliest configuration we can achieve over the telephone |
| network involves two computers only, where one computer would |
| be acting as server and another as client. In this |
| configuration, the client computer establishes connection to |
| the server to make use of internet services provided therein. |
| </para> |
| |
| <para> |
| When the client computer calls the server computer, the call |
| is attended by <application>mgetty</application> and then |
| passed to <application>pppd</application> for establishing a |
| PPP conversation between the two computers. The first thing |
| in a PPP conversation is the user authentication and then |
| (after a sucessful athentication), the IPCP conversation takes |
| place to set IP addresses and start data transmission over the |
| link recently created. In this configuration, the client |
| computer can set its IP address when configuring the Modem |
| device (see <xref |
| linkend="connectivity-ppp-modem-config" />) or |
| leave the server computer to assign one (assuming you are |
| calling a server computer). If you are configuring a server |
| computer, then it is necessary that you set the IP address and |
| netmask of the IP network you are planning to set, using the |
| Modem device configuration file. |
| </para> |
| |
| <para> |
| Configuring the IP address and netmask information inside |
| Modem device configuration file is very important in order to |
| prevent errors when transmitting data across the link. When |
| the the netmask information isn't set in the Modem device |
| configuration file, the <systemitem |
| class="daemon">pppd</systemitem> daemon on the server computer |
| tries to retrive such information from the client computer and |
| if the client computer didn't specify one either, the network |
| recently created would end up having a wrong information |
| (e.g., <systemitem |
| class="netmask">255.255.255.255</systemitem>) which provokes |
| the point-to-point connection to fail when someone tries to |
| transfer data through it. |
| </para> |
| |
| <figure id="connectivity-ppp-policy-network-basic"> |
| <title>One PPP network of two computers</title> |
| <screenshot> |
| <screeninfo>One PPP network of two computers</screeninfo> |
| <mediaobject> |
| <textobject> |
| <screen> |
| Provice-A PPP Server Province-A PPP Client |
| --------------------------\ /-------------------------- |
| 192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 |
| --------------------------/ \-------------------------- |
| </screen> |
| </textobject> |
| </mediaobject> |
| </screenshot> |
| </figure> |
| |
| <para> |
| The <xref linkend="connectivity-ppp-policy-network-basic" /> |
| describes the simpliest configuration we can implement for a |
| point-to-point connection. This configuration involves two |
| computers only, one acting as server (the server computer) and |
| other acting as client (the client computer). The client |
| computer calls the server computer to establish a PPP |
| connection in order to use whatever internet service the |
| server computer provides. In the figure we can see that there |
| are two IP addresses involved (<systemitem |
| class="ipaddress">192.168.1.1</systemitem> and <systemitem |
| class="ipaddress">192.168.1.2</systemitem>) inside the same |
| newtork (<systemitem |
| class="netmask">255.255.255.0</systemitem>). |
| </para> |
| |
| <para> |
| This configuration might be convenient for people in the same |
| location, near one another. Here, the client computer |
| establishes connection by mean of a local telephone call and |
| can use whatever internet service the server computer |
| provides. Since the connection lifetime is limited (see <xref |
| linkend="connectivity-ppp-policy-lifetime" />) and only two |
| peers can be connected at the same time (assuming only one |
| Modem is attached to the server computer), the implementation |
| of some internet services like chat may be not a practical |
| offer for the server computer to provide. However, internet |
| services like e-mail fit perfectly on this environment where |
| more than one client computer would be struggling among |
| themselves for establishing connection with the server |
| computer (e.g., people connect to send/receive their e-mail |
| messages to/from the server computer). |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-network-extended"> |
| <title>One PPP Network Of Several Computers</title> |
| |
| <para> |
| Based on <xref |
| linkend="connectivity-ppp-policy-network" />, it is |
| possible to provide an extended version including several |
| server computers that may communicate between themselves to |
| distribute data collected from client computers they serve to. |
| For example, consider the telephone network of a country which |
| is organized in provinces and each province is divided in |
| several municipalities. In such organization, it would be |
| possible to set one or more server computers for each province |
| and let near people to dial-up on them to use whatever |
| internet service they provide. Later, it could be possible |
| for each server computer to establish a dial-up connections |
| with other near server computers in order to share information |
| from one province to another, as it is illustrated in <xref |
| linkend="connectivity-ppp-policy-network-extended.fig-1" |
| />. |
| </para> |
| |
| <para> |
| When setting the IP information, it is important that each |
| server computer sets both IP address and IP network mask |
| information in the Modem device configuration file so |
| different IP address can be use between different server |
| computers. It is also important that they all be configured to |
| use authentication between themselves before transmitting any |
| data across a PPP established connection so the information |
| being transmitted can be protected. |
| </para> |
| |
| <para> |
| When making telephone calls, if someone in Province-A needs to |
| send a message to someone in Province-C (which is far away |
| from Province-A and making a telephone call there would imply |
| a considerable amount of money), there is no need (even it is |
| possible and sometimes prefered) for that person to realize a |
| direct telephone call from Province-A to Province-C. Instead, |
| that person in Province-A can send its messages to the server |
| computer on its province (the nearest server on its location) |
| making a local telephone call and then, such server computer |
| would take care of delivering the information using other |
| server computers, following the same concept of nearest |
| delivery. |
| </para> |
| |
| <figure id="connectivity-ppp-policy-network-extended.fig-1"> |
| <title>One PPP network of several computers</title> |
| <screenshot> |
| <screeninfo>One PPP network of several computers</screeninfo> |
| <mediaobject> |
| <textobject> |
| <screen> |
| Provice-A PPP Server Province-A PPP Client |
| --------------------------\ /-------------------------- |
| 192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 |
| --------------------------/ | \-------------------------- |
| | |
| Provice-B PPP Server | Province-B PPP Client |
| --------------------------\ | /-------------------------- |
| 192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 |
| --------------------------/ | \-------------------------- |
| | |
| Provice-C PPP Server | Province-C PPP Client |
| --------------------------\ | /-------------------------- |
| 192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 |
| --------------------------/ \-------------------------- |
| </screen> |
| </textobject> |
| </mediaobject> |
| </screenshot> |
| </figure> |
| |
| <para> |
| The more distant a telephone call is, the more expensive it |
| is. This way, to move information from one province to |
| another, each server computers must be configured to send |
| information to the nearest province until reaching its |
| destination. For example, if you are in Province-A and want to |
| send an e-mail message to Province-D, the server computer |
| configured in Province-A must sed the e-mail message to |
| Province-B, then server in Province-B must be configured to |
| send such message to Province-C, and finally C to D. This is |
| required because making a direct call from Province-A to |
| Province-D would be otherwise too much expensive to pay. |
| </para> |
| |
| <para> |
| Since telephone calls are required to establish connections |
| between computers and each call costs money based on the |
| location and the destination, it is required to set a |
| convenction in how telephone calls are realized from one |
| server computer to another, specially if you plan to establish |
| connection between server computer placed on different |
| provices in order to exchange data between them. |
| </para> |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| Do you make direct telephone calls to make direct data delivery? |
| — This configuration could be very expensive to maintain |
| (considering the telephone call distances), but data will be |
| delivered very fast to their destinations. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Do you call the nearest server computer and let it to deliver |
| your data to its destination? — This configuration could |
| be less expensive to maintain (considering the telephone call |
| distances), but data delivery will take much more time to |
| reach their destinations and there is no way to be sure it |
| will do. |
| </para> |
| |
| </listitem> |
| </itemizedlist> |
| |
| <para> |
| Whatever calling schema be chosen, the server computers will |
| always talk through UUCP to transfer data from one place to |
| another. The server computers will operate with two IP |
| addresses each, unless you plan to connect one of the server |
| computers to a different network (Internet, maybe?). One IP |
| address would identify the server computer itself and the |
| other would identify the client computer establishing PPP |
| connection to the server computer. In this configuration it |
| is very importat that each server and client computer does |
| have one unique IP address. This way it would be possible to |
| move the information from one computer to another. Notice that |
| the number of PPP clients is directly related to the number of |
| telephone lines a server computer has configured to receive |
| incomming calls on. If there is only one telephone line |
| attached to the server computer then, only one client computer |
| will be able to establish connection to that server computer. |
| Other PPP clients will need to wait until the telephone line |
| gets free in order to establish connection with that server |
| computer. On the other hand, if the server computer has two |
| (or more) attached telephone lines, it would be possible to |
| attend incoming calls from two (or more) PPP client at the |
| same time. As resume, we can say that: the more telephone |
| lines the server computer has attached in, the more |
| simultaneous connections that computer will be able to |
| attend/realize from/to other computers. |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-network-eth"> |
| <title>One PPP+Ethernet Network Of Several Computers</title> |
| |
| <para> |
| Assuming all server computers with a Modem device have also |
| one (or more) Ethernet interface attached (which is very |
| common nowadays), it would be possible to extend the |
| configuration described in <xref |
| linkend="connectivity-ppp-policy-network-extended.fig-1" /> |
| creating one Ethernet network for each server computer in the |
| configuration. For this configuration to be implemented it is |
| required one or more switch devices (based on the amount of |
| computers such network needs to have) for each ethernet |
| network interface a server computer has, as described in <xref |
| linkend="connectivity-ppp-policy-network-extended.fig-2" |
| />. |
| </para> |
| |
| <figure id="connectivity-ppp-policy-network-extended.fig-2"> |
| <title>One PPP+Ethernet network of several computers</title> |
| <screenshot> |
| <screeninfo>One PPP+Ethernet network of several computers</screeninfo> |
| <mediaobject> |
| <textobject> |
| <screen> |
| Province-A PPP/ETH Server Province-A PPP Client |
| --------------------------\ /-------------------------- |
| 192.168.1.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.2/24 |
| --------------------------/ | \-------------------------- |
| 192.168.0.1/24 | Ethernet | |
| ---------------------|---- | |
| | | |
| +--------+ | |
| | Switch | | |
| +--------+ | |
| | | |
| ---------------------|-- | |
| LAN1: 192.168.0.2-254/24 | |
| ------------------------ | |
| Province-A ETH Clients | |
| | |
| Province-B PPP/ETH Server | Province-B PPP Client |
| --------------------------\ | /-------------------------- |
| 192.168.1.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.4/24 |
| --------------------------/ | \-------------------------- |
| 192.168.2.1/24 | Ethernet | |
| ---------------------|---- | |
| | | |
| +--------+ | |
| | Switch | | |
| +--------+ | |
| | | |
| ---------------------|-- | |
| LAN2: 192.168.2.2-254/24 | |
| ------------------------ | |
| Province-B ETH Clients | |
| | |
| Province-C PPP/ETH Server | Province-C PPP Client |
| --------------------------\ | /-------------------------- |
| 192.168.1.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.1.6/24 |
| --------------------------/ \-------------------------- |
| 192.168.3.1/24 | Ethernet |
| ---------------------|---- |
| | |
| +--------+ |
| | Switch | |
| +--------+ |
| | |
| ---------------------|-- |
| LAN3: 192.168.3.2-254/24 |
| ------------------------ |
| Province-C ETH Clients |
| </screen> |
| </textobject> |
| </mediaobject> |
| </screenshot> |
| </figure> |
| |
| <para> |
| In this configuration, computers connected to the switch will |
| also be considered as client computers. It is necessary that a |
| coordination be implemented at time of setting IP addresses to |
| new server computers so no IP address be duplicated on the |
| computer network. The illustration above describes one main |
| network (<systemitem |
| class="ipaddress">192.168.1/24</systemitem>) which connects |
| all the server computers using the telephone lines as medium |
| for data transmission. The Modem interface connects just one |
| computer at a time either client or server (assuming only one |
| Modem device is installed and configured in |
| the computer acting as server). The telephone line is used by |
| client computers to establish PPP connections with the server |
| computer and by server computers to exchange data with other |
| server computers, as well. On the other hand, the ethernet |
| interface attached to each server computer let the |
| administrator of each server computer to connect up to 252 |
| computers simultaneously, assuming a class C network as shown |
| above be used.<footnote> |
| <para> |
| There are also class A and class B network types which can be |
| used to connect much more computers than a class C network |
| allows to. |
| </para> |
| </footnote> |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-bridgedcall"> |
| <title>About Bridging Calls To Transfer Data</title> |
| |
| <para> |
| When the server computers call other server computers to |
| bridge data delivery, the server computer in, let's say, |
| Province-A (srv-1.a.domain.tld) will never know that there is |
| a server computer on Province-C (srv-1.c.domain.tld) or |
| Province-D (srv-1.d.domain.tld), but in Province-B |
| (srv-1.b.domain.tld) |
| only, its nearest location. So, when a message is sent from |
| srv-1.a.domain.tld to the server computer in |
| srv-1.d.domain.tld, the server computer in srv-1.a.domain.tld |
| contacts its nearest server computer (i.e., |
| srv-1.b.domain.tld) and delivers to it all messages sent to |
| srv-1.d.domain.tld. Later, since srv-1.b.domain.tld doesn't |
| know about srv-1.d.domain.tld server either, it delivers all |
| messages directed to srv-1.d.domain.tld to its nearest server |
| computer (i.e., srv-1.c.domain.tld). Later, the server |
| computer in srv-1.c.domain.tld, which knows about |
| srv-1.d.domain.tld, delivers to it all the messages it has for |
| it. Notice that, in order for this configuration to work, |
| system administrators attending the server computers must work |
| syncronized to garantee a well defined route for messages to |
| follow. Otherwise, if one of the server computers in the path |
| creates a route for a server computer that doesn't exist |
| (or doesn't define a route at all), the information will never |
| reach its destination when such computer is acting as a bridge |
| between other two server computers. |
| </para> |
| |
| <screen> |
| +------------------------+ +------------------------+ +------------------------+ +---------------------+ |
| | To: bob@d.domain.tld | | To: bob@d.domain.tld | | To: bob@d.domain.tld | | Bob's mailbox | |
| | From: mat@a.domain.tld | | From: ana@b.domain.tld | | From: jef@c.domain.tld | | (Final destination) | |
| | Body: 500KB | | Body: 500KB | | Body: 500KB | | | |
| +---|--------------------+ +---|--------------------+ +---|--------------------+ +------------------^--+ |
| | | | | |
| ----v--------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|------------------|--- |
| srv-1.a.domain.tld | 75Km Call | srv-1.b.domain.tld | 75Km Call | srv-1.c.domain.tld | 75Km Call | srv-1.d.domain.tld |
| -------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|---------------------- |
| relay to: | 5 min | relay to: | 10 min | relay to: | 15 min | |
| srv-1.b.domain.tld | 500KB | srv-1.c.domain.tld | 1.0MB | srv-1.d.domain.tld | 1.5MB | |
| </screen> |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-directcalls"> |
| <title>About Directing Calls To Transfer Data</title> |
| |
| <para> |
| When the server computers make direct telephone calls (no |
| bridge in-between is used to transfer data), the server |
| computer in Province-A (srv-1.a.domain.tld) contacts the |
| server computer in Province-D (srv-1.d.domain.tld) making a |
| direct telephone call up to it. In this configuration, the |
| telephone call might cost more than those in a bridged |
| configuration where several smaller telephone calls are dialed |
| in-between the final server computer; or less, considering |
| that when server computers in a bridged configuration exchange |
| data they may move data accumulated from other server |
| computers, while a direct telephone call would transmit data |
| from one server computer to another without any accumulated |
| data from other server computers. There is no need to |
| overload the server computers with foreign data when each |
| server computer could call themselves to transfer data |
| directly. |
| </para> |
| |
| <screen> |
| +------------------------+ +---------------------+ |
| | To: bob@d.domain.tld | | Bob's mailbox | |
| | From: mat@a.domain.tld | | (Final destination) | |
| | Body: 500KB | | | |
| +--|---------------------+ +------------------^--+ |
| | | |
| ---v---------------------|<~~~~~~~~~~>|-------------------|--- |
| srv-1.a.domain.tld | 225Km Call | srv-1.d.domain.tld |
| -------------------------|<~~~~~~~~~~>|----------------------- |
| relay to: | 5 min | |
| srv-1.d.domain.tld | 500KB | |
| </screen> |
| |
| <para> |
| The elapsed time in a server-to-server conversation is |
| directly related to the amount of data that need to be moved |
| from one server to another and the baud rate of the connection |
| established between the two Modem devices. In a direct |
| telephone call configuration, telephone calls could result to |
| be less expensive than those in bridged configurations where |
| server computers may accumulate traffic from other server |
| computers in the path. The accumulation of traffic between |
| server computers increases the amount of time the last server |
| computer in the path before the final destination needs, in |
| order to transmit everything to the final destination. In a |
| bridged telephone call configuration, server computers acting |
| as bridges do act as servers as well and produce their own |
| traffic which is added to that one already accumulated in |
| them from other server computers. This may provoke a heugh |
| traffic in a server-to-server conversation (remarkably on the |
| last destination before the final destination), that could be |
| potentially increased with each new server computer added to |
| the string of server computers acting as bridges one another. |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-auth"> |
| <title>About Authenticating PPP Users</title> |
| |
| <para> |
| The client computers will need to authenticate against the |
| server computer each time they intend to establish a PPP |
| connection. The username and password required by client |
| computers will be public and will be rarely changed. |
| </para> |
| |
| <example id="connectivity-ppp-policy-auth.fig-1"> |
| <title>Credentials for PPP authentication</title> |
| <screenshot> |
| <screeninfo>Credentials for PPP authentication</screeninfo> |
| <mediaobject> |
| <textobject> |
| <screen> |
| ISP Name: projects.centos.org |
| ISP Phone: +53043515094 |
| Username: faith |
| Password: mail4u.2k10 |
| </screen> |
| </textobject> |
| </mediaobject> |
| </screenshot> |
| </example> |
| |
| <para> |
| The server computer provides only one telephone line available |
| (e.g., +53043515094) to receive incoming calls. This affects |
| directly the possibilities a client computer has to establish |
| connection with the server computer in an environment where |
| several client computers are struggling among themselves to |
| establish a dial-up connection with the server computer. To |
| prevent this kind of issues from happening, it is innevitable |
| for the server computer to provide more telephone lines for |
| incoming calls (at least one for each user the server computer |
| expects to receive incoming calls from). |
| </para> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-policy-lifetime"> |
| <title>About Restricting PPP Connections</title> |
| |
| <para> |
| The server computer restricts the lifetime of established |
| Modem connections to 15 minutes from the establishment moment |
| on. Once the connection has been established, if the link is |
| idle for 1 minute, the server computer will also close the |
| established connection to free the telephone line. This |
| control can be implemented through the |
| <option>maxconnect</option> and <option>idle</option> options |
| inside the <application>pppd</application>'s configuration |
| file as described in <xref |
| linkend="connectivity-ppp-server-pppd-options" />. |
| </para> |
| |
| <para> |
| The server computer restricts the incoming calls from client |
| computers every night from 10:00PM to 12:00AM. Outside this |
| range of time, the telephone could be answered by a person, |
| not a computer. This control can be implemented through a cron |
| job and the <filename>/etc/nologin.ttyxx</filename> file; |
| where ttyxx represents the device name of your Modem (e.g., |
| <filename>/etc/nologin.ttyACM0</filename> would prevent the |
| Modem device installed in <filename>/dev/ttyACM0</filename> |
| from answering calls). |
| </para> |
| |
| <screen> |
| # Activate Modem to attend incoming calls. |
| 59 21 * * * [ -f /etc/nologin.ttyACM0 ] && /bin/rm /etc/nologin.ttyACM0 |
| # Deactivate Modem to prevent incoming calls from being attended. |
| 59 23 * * * [ ! -f /etc/nologin.ttyACM0 ] && /bin/touch /etc/nologin.ttyACM0 |
| </screen> |
| |
| </sect2> |
| |
| <sect2 id="connectivity-ppp-services"> |
| <title>About Providing Internet Services</title> |
| |
| <para> |
| The implementation of internet services which require |
| persistent connections (e.g., |
| <application>chats</application>) should not be considered as |
| a practical offer for PPP client computers. Instead, only |
| asynchronous services (e.g., |
| <application>e-mail</application>) should be supported for |
| them. This restriction is required to reduce the connection |
| times demanded such services. For example, consider an |
| environment where you establish connection with a server |
| computer to send/receive e-mails messages and then quickly |
| disconnect from it to free the telephone line so others be |
| able of using it. In this environment, there is no need for |
| you and others to be both connected at the same time to |
| send/receive e-mail messages to/from each other. The e-mails |
| sent from other person to you will be available in your |
| mailbox the next time you get connected to the server computer |
| and use your e-mail client to send/receive e-mail messages. |
| Likewise, you don't need to be connected to the server |
| computer in order to write your e-mail messages. You can |
| write down your messages off-line and then establish |
| connection once you've finished writing, just to send them out |
| and receive new messages that could have been probably sent to |
| you. |
| </para> |
| |
| <para> |
| Another issue related to e-mail exchange is the protocol used |
| to receive messages. Presently, there are two popular ways to |
| do this, one is through IMAP and another through POP3. When |
| you use IMAP protocol, e-mail messages are retained in the |
| server computer and aren't downloaded to client computer. |
| Otherwise, when you use POP3 protocol, e-mail messages are |
| downloaded to the client computer and removed from server |
| computer. Based on the resources we have and the kind of link |
| used by the client computer to connect the server computer, |
| using POP3 is rather prefered than IMAP. However both are made |
| available. |
| </para> |
| |
| <para> |
| Assuming you use IMAP protocol to read your mailbox, be aware |
| that you need to be connected to the server computer. Once |
| the connection is lost you won't be able to read your messages |
| (unless your e-mail client possesses a feature that let you |
| reading messages off-line). Moreover, you run the risk of |
| getting your mailbox out of space. If your mailbox gets out of |
| space, new messages sent to you will not be deliver to your |
| mailbox. Instead, they will be deferred for a period of time |
| (e.g., about 5 days when using |
| <application>Postfix</application> defaults) hoping you to |
| free the space in your mailbox to deliver them. If you don't |
| free space on your mailbox within this period of time, the |
| deferred e-mails will be bounced back to their senders and you |
| will never see them. On the other hand, assuming you are |
| using POP3 protocol to read your mailbox, you always keep your |
| mailbox free to receive new e-mails messages and keep them for |
| you until the next time you establish connection with the |
| server computer and download them to your client computer |
| using your e-mail client. |
| </para> |
| |
| <para> |
| The information generated inside the server computer is |
| isolated from Internet. This way, any information generated |
| inside the server computer will be available only to people |
| connected to the same network the server computer is connected |
| to. For example, don't ever expect to send/receive e-mails |
| to/from Internet e-mail accounts like Gmail or Yahoo, nor |
| visiting web sites like <ulink |
| url="http://www.google.com/">Google</ulink> or <ulink |
| url="http://www.wikipedia.org/">Wikipedia</ulink> either. For |
| this to happen, an established connection must exist first |
| between the server computer you are establishing connection |
| through and the Internet network those services are available |
| in. Without that link, it is not possible to direct your |
| requests to those sites, nor receive any response from them. |
| </para> |
| |
| </sect2> |
| |
| </sect1> |