In this post I will try to show the the basic outline of a telecentre. I’ll try to emphasize the reasoning, right or wrong, of certain design decisions. It is also essential for me to point out that this development has been the product of a team, which I had the great honor of coordinating: so all credit goes to Alfredo Matas, Javier Hernandez, David Teyssiere, Enrique Jimenez, Jose Ignacio Alvarez and Roberto C. Morano.
Structure of a telecentre
A telecentre as conceived in this project, is a set of computers for both local activities and navigation, with a series of restrictions aimed at maintaining the system stability over time, the privacy of the users, and remote control of the entire system by the support team. The telecentre is unattended (there is no personnel for its management), and therefore the system must allow access to users in a simple and clear way.
Connection technology for the LAN
Technically, we’re talking about a local network with a series of connected computers (“clients”) and printers. The way these computers would be connected, or rather the technology used for it was one of the first issues addressed.
The technical team called for the complete wiring of the centres. We have experience in the use of WiFi in production environments thanks to the Guadalinfo project, and we are aware of the instability, unreliability and limited bandwidth of this technology. Much of the problems experienced in Guadalinfo are due to use of WiFi technology, so our first recommendation was, as I said, the wiring of schools.
However, due to logistical problems, the wiring was not possible so the WiFi technology was the only option. I must say that despite the problems mentioned, this technology offers an important advantage: the network topology can not be changed by the users. This is an important advantage: in Guadalinfo, altering the network topology is a major cause of incidents. If we add that we are dealing with unattended centres, and therefore without surveillance, this advantage is even more so.
Another issue that arose during the design was whether or not there would be a server in each telecentre, offering the services required to operate it, or if on the other hand there would be a center without a server.
At first glance, the option of having a server in the center is very attractive. It offers much flexibility (you can enable any service deemed necessary if the hardware is capable of serving it), the control of the center is more precise and the development may seem (apparently) easier. Also:
- The server can provide services that otherwise would be offered remotely. This is even more relevant if we consider that the telecentres are in some of the most inaccessible parts of Andalusia, and the available broadband connections are unstable and provides low bandwidth.
- If new needs appears in the future, they can be met more easily by having a server for hosting services.
- It simplifies development of client distribution, not having to include many configuration for accessing remote services.
- This model was applied Guadalinfo: a server that operates as a router for the internal network from the center, offers all kind of services to the client computers, and is controlled remotely by the technical team and in person by the coordinator of the center (a figure that does not exists in the telecentres we are dealing with).
But this model has more drawbacks than those perceive at first glance. The server is a single point of failure, does not provides so many advantages in an unattended center, and our experience tells us that it offers more problems than initially perceived. To be more explicit:
- A server is a single point of failure: be aware that many of the centers where the equipment is installed have a faulty electrical installation, with frequent power cut, and therefore hardware failures are more frequent than at first it might seem.
- In an unattended center, there is not much sense to a local server: there is no need for a classroom control software, or shared directories, and so on.
- Enabling a server in the center involves the development and support of two different versions of the software: it is necessary to develop two “flavors” of the distribution, one for clients and one for servers. What you save reducing the clients configuration efforts, you lose by having to develop two distros.
- Any user could turn off the server mistaking it for a client computer, leaving all the telecentre without service.
Therefore, which option have we adopted? Well, we have chosen a server scheme, but implemented using a router that supports dd-wrt, and that offers the following services:
- Connects the center to the VPN we have enabled for the network of telecentres, both itself and the clients, offering a unique VPN IP address for each one through DHCP. Authentication is done through digital certificates, each one unique to each center.
- Allows the monitoring of the center connectivity.
- Offers DNS service.
- Routes the traffic of the remote services through the VPN, leaving the browsing traffic out of it.
- Prioritizes VPN traffic over web browsing, using QoS.
- Stores the printer’s MAC and assigns the second IP of the range assigned to each center.
By having an intermediate model between the complete absence of a server in the center, and the presence of the one, we have advantages that made us opt for this model:
- We have a single point of failure, but a server repair is more expensive and time consuming than replaceing a defective router, which is much quicker and cheaper.
- The reliability and stability of a network device is higher than that of a consumer computer hardware.
- The router is able to provide basic services needed for a center without finding unmet needs (at least for now).
Therefore, the structure of a telecentre is formed by a smart router using a custom, dd-wrt based firmware, and a number of clients and printers connected to it via wireless. The router, in turn, is connected to the ADSL/LMDS/VSAT router which in each case provides Internet connectivity to the center.
You see, we tried to apply all the experience gained in previous projects of telecentres and have developed what we think is a simple structure, less prone to errors as possible, with the resources at our disposal. Comments, opinions, critics?