Linux as an Internet Kiosk
Our network is a mishmash of random hardware and hand-built software. Coming into Café Liberty are two 384Kbps fractional T1 lines. One runs to our ISP and provides Internet service using the Cisco HDLC protocol. The other is a frame-relay line that serves the NetPods. The two T1s are attached to our router (a 486DX/40 running Linux), which also has two Ethernet cards. One Ethernet is for the café (including network jacks for public use), and the other is for NetPod machines.
You don't often hear of a single Linux box being used as a router for multiple Ethernets and T1 lines with differing protocols, let alone a wimpy 486DX/40. But, thanks to SDL Communications' RISCom/N2 cards, it is possible. One RISCom/N2 with a T1 CSU/DSU attached to its v.35 port runs the frame-relay connection, and the other RISCom/N2csu (with built-in CSU/DSU) runs the Cisco HDLC Internet connection.
Getting the cards up and running is mostly straightforward, though there are many small details, like electrical characteristics of the T1 lines, that we sometimes had to just guess at and hope it worked. After the cards were up, routing was easy—just compile IP forwarding into the kernel, set up some subnets and all falls into place.
The NetPod Ethernet has only a couple of machines on it, the most important of which is the NetPod server. The server is a Pentium 100 (running Linux) with 32MB of RAM that deals with NetPod mail (using ZMailer), the Usenet feed (inn), NFS serving of users' home directories, and the NetPod database. The database, which keeps track of user information, was custom-written and communicates with the NetPods over encrypted channels for security.
The server has IP firewalling turned on in full force. While anybody can connect to the SMTP, POP and IMAP daemons, everything else (most specifically NFS) is tightly controlled.
Each NetPod has a 56Kbps frame-relay connection. As far as we know, we are the only Internet terminal company in the world to have chosen frame-relay; the vast majority use standard phone lines and a couple use ISDN. Each frame-relay line is assigned a different PVC (Permanent Virtual Circuit) number. Their data is consolidated and appears on the frame-relay T1 at café Liberty.
Though frame-relay may seem like massive overkill for an Internet terminal, it has enormous benefits.
Frame-relay is fast. The latency on frame-relay lines is a lot less than a PPP connection over a modem. This translates directly into faster TCP connection times for Netscape. We are guaranteed 56Kbps of bandwidth, while the average 33.6Kbps or 56Kbps modem is unlikely to ever get its theoretical maximum bandwidth.
Frame-relay is cheap. Our lines cost somewhere around $150 a month. This may seem like a quite a premium to pay for the comparatively mediocre speed benefits mentioned above, but remember that Massachusetts is in NYNEX (phone company for northeast U.S.) territory. [NYNEX, which covered the east coast of the U.S. from Maine to New York, and Bell Atlantic, which covered from new Jersey south to Virginia, have just merged. The combined company is Bell Atlantic—Ed.] We have found that NYNEX would charge us thousands of dollars per month for a 64Kbps ISDN connection up 24 hours a day. The situation with standard analog dial-ups isn't much better; there is simply no way to avoid a ludicrous per-minute charge on business phone lines of any type.
Thus, frame-relay was the obvious choice. Yet the startup costs for frame-relay are crippling. One SDL RISCom/N2dds (with built-in 56Kbps CSU/DSU) and frame-relay software costs $750. The installation costs for the line are several hundred more. Despite these numbers, we feel that there are very real benefits to the frame-relay technology. Being able to remotely access the NetPods at any time of day or night is immensely useful.
In an attempt to reduce the cost of frame-relay, we have embarked on a side project to add frame-relay support to Linux. We had often wondered why Linux had no frame-relay protocol driver. It seems that the main reasons are complexity and cost. You can tell that parts of frame-relay were designed by committee; every person involved managed to get his or her pet feature fit in somewhere, yet they don't all fit quite right. All the relevant standards documents have to be purchased from the ITU (International Telecommunications Union) and then deciphered.
We figure we can drop the cost of frame-relay about $500 if we use a BAT Electronics CSU/DSU (the most inexpensive we could find) and then tack on a minimalist synchronous to asynchronous converter of our own design. This converter takes the CSU/DSU's synchronous bitstream, repackages it in RS-232 bytes at 115,200 baud and sends it to the NetPod, which then interprets it with the frame-relay driver. As of early June, we have established successful TCP connections through this system, and we are now concentrating on improving the stability and performance of the drivers. Once they are ready for release, we will donate the drivers to the standard kernel distribution so that any device that generates an HDLC-framed bitstream (like Z8530-based synchronous cards) can be used for frame-relay.
We are a 100% Linux shop. Except for some graphics work that we do on Macintoshes to keep professional printers happy, every last machine is a PC running Linux. Linux has given us so much that, in the true spirit of Linux, we feel we have to give something back to the community, which we hope to do with our frame-relay package.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- Android's Limits
- Reachli - Amplifying your
1 hour 8 min ago
1 hour 57 min ago
- good point!
2 hours 25 sec ago
- Varnish works!
2 hours 9 min ago
- Reply to comment | Linux Journal
2 hours 39 min ago
- Reply to comment | Linux Journal
5 hours 5 min ago
- Reply to comment | Linux Journal
9 hours 4 min ago
- Yeah, user namespaces are
10 hours 21 min ago
- Cari Uang
13 hours 52 min ago
- user namespaces
16 hours 45 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?