How to Build an Internet App

A little Visual Basic code, a connection to the Internet, and you've got your own weather channel

Brett Glass

Have you been thinking about writing software for the Internet? Perhaps you're worried that the conventions and protocols would require years to master. As it turns out, programming for the Internet is quite simple. I'll demonstrate that fact in this article. In the process, with just a bit of pointing and clicking and about a page-and-a-half of code, you'll learn how to create a potentially life-saving Internet application. First, I should explain how Internet programming got to be so simple.

Multiplatform Simplicity

In the early days of wide-area networking, research institutes want ed to connect hundreds of different brands of micros, minis, and mainframes to what was then the ARPANET, an experimental research network (which is now the Internet). At that time, far more hardware architectures and operating systems were in use than today. For example, the time-sharing system of choice at many colleges and laboratories was the DECSystem-20 superminicomputer (DEC-20 for short). This unusual machine had a 36-bit word size, ran several powerful operating systems, and processed text as 7-bit ASCII characters.

Other machines on the Net included mainframes, Unix boxes, VAXen running VMS, Macs, IBM PCs, Apple IIs, and even CP/M machines. To minimize the effort required to bring networking to all these platforms, no Internet protocol could make many assumptions about the underlying architecture of the machine. Each Internet protocol was designed to be so simple that a capable graduate student could reimplement it on a new type of machine in a matter of days or weeks.

The Internet stand ardization process was also unique. Today, standards are established largely by fiat: A big company (say, Microsoft) introduces a product whose file format or communication protocol is adopted by other companies.

This was not true on the ARPANET, whose population of scholars and computer hackers had little to gain from the promotion of complex, proprietary standards. A new protocol's author would first implement and test the protocol, then write a descriptive paper known as a Request for Comment (RFC). This paper was "posted" on the network, where other programmers could comment on it. Only after many sites had implemented the protocol, found it useful, and provided their input would the protocol become -- by consensus -- a true standard. (You can obtain RFCs via FTP from the Internet site NIC.DDN.MIL. Or you can get them on CD-ROM from Walnut Creek; phone (800) 786-9907.)

TCP/IP and the OSI Reference Model

The protocol suite that emerged from the ARPANET standards process is TCP/IP (every other standard created through ARPANET, in one way or another, is connected with TCP/IP). TCP/IP has "layers" ranging from the physical signals that travel along wire or fiber to the messages or commands sent to one another by application programs. The International Standards Organization's Open Systems Interconnect (OSI) Reference Model, a generic set of protocol layers, helps to put the parts of TCP/IP into perspective ( see the table ).

IP, the Internet Protocol, implements the network layer, which handles routing of information between networks. TCP, the Transmission Control Protocol, implements the transport layer, which paces transmissions, keeps the data in order, and ensures that it arrives without errors. UDP, the User Datagram Protocol (and another part of the TCP/IP suite), sends "raw" datagrams, or messages without error checking. In a sense, it's a "null" implementation of the transport layer, which is why it's sometimes called the Unreliable Datagram Protocol.

The TCP/IP suite contains many application-layer protocols -- conventions that applications use to talk to other applications. These include the Simple Mail Transfer Protocol (SMTP), Telnet (terminal emulation), FTP (file transfer protocol), network news transfer protocol (NNTP), Gopher (the University of Michigan's distributed, text-based menu system), and the Hypertext Transport Protocol (HTTP) that, together with the Hypertext Markup Language (HTML), implements the World Wide Web.

Since many computers already come with complete implementations of TCP, UDP, IP, and Berkeley Sockets (a handy API that makes it easy to establish sessions with remote hosts), the application layer is where the action is. Virtually all the innovative new Internet programs work with existing application-layer protocols or create new ones. Most Internet application-layer protocols are very simple and send messages in formats easily readable by humans, making them a joy, rather than an ordeal, to implement. I'l l use one of the simplest protocols of all -- Gopher -- to retrieve information in the sample application that follows.

Where's Felix?

To demonstrate how easy it is to write Internet software, I recently developed a timely Internet application in 30 minutes in front of a live audience at One BBSCon in Tampa, Florida. At the time, Hurricane Felix was raging in the Atlantic, and southeasterners from the Carolinas to Florida were concerned that it might be headed their way. So, to allow them to track the hurricane easily, I developed a Windows program that would display information about the storm, with updates every 15 minutes. The application included an "instant update" button, which the user could click to retrieve the absolute latest information.

Because I had only about an hour for my entire lecture, I used Microsoft's Visual Basic 3.0 in conjunction with a shareware VBX (Visual Basic control) called IPPort, published by devSoft Inc. (Research Triangle Park, NC). You ca n get this and other VBXes from devSoft's Web site at http://www.dev-soft.com . IPPort interfaces to WinSock, the Windows variant of the Berkeley Sockets API, and in doing so insulates you from the complexity of dealing directly with WinSock. (WinSock and Berkeley Sockets are session-layer APIs for TCP/IP.)

The source code for the hurricane tracker, including copious comments and subroutine headings (generated by Visual Basic), is only 90 lines long. (You can download the complete source from the BYTE Web site at http://www.byte.com .) The application starts by establishing a connection to a Gopher server at the University of Indiana that contains frequently updated hurricane information. Making the connection requires only three lines of code, which set properties in the IPPort control:

IPPort1.HostName = "wx.atmos.uiuc.edu"
IPPort1.Port = 70
 'Gopher
IPPort1.Connected = True

A property is a variable associated with a Visual Basic component or control. Usually, when you assign a new value to a control's property, it has side effects: For example, setting a button's property might cause it to change color. In the above listing, assigning a host's domain name to the IPPort control's HostName property causes the control to look up the name, determining its IP address in preparation for a connection.

The second statement assigns an IP port number for the connection. In TCP/IP lingo, the word port has an unusual meaning: It specifies the process or application with which you'd like to communicate on the remote host. Opening a connection with port number 70 indicates that your program would like to talk to the host's Gopher server (if one is running), while connecting to port numbers 23 and 79 invoke Telnet and Finger, respectively. The numbers which, by convention, invoke standard TCP/IP applications are known as "well-known ports."

The third statement starts the conversation with the remote machine. When the Connected property is set to True , the custom control "makes it so" by attempting a connection to the remote machine. The program can read the Connected property to determine whether a connection actually has been established; a trappable run-time error occurs if there is a problem.

The first three statements

'Wait until we are connected
Do Until IPPort1.Connected: DoEvents: Loop
tResponse.Text = "Polling gopher server...." &
  Chr$(13) & Chr$(10)
'Send request
IPPort1.DataToSend =
 "0/Hurricane Advisories and Images/Atlantic-Discussion" &
 Chr$(10)

watch for a successful connection (yielding control to other Windows apps in the interim), place a message in the sidebar to indicate that a connection has been made, and request data from the Gopher server.

Asking a Gopher server for information is as simple as setting one other pr operty -- the IPPort control's DataToSend property -- to a string containing the text of the request. To retrieve information from a Gopher server, the client just sends a text string indicating what it wants. (Most often this string is in the form of a filename.) The server delivers the data and ends the connection.

When data begins to flow in, it triggers a Visual Basic event handler -- a procedure that responds to events such as mouse movements, keystrokes, and incoming network data. The event handler, a subroutine with the name IPPort1_DataIn , places the incoming data in the sidebar:

Sub IPPort1_DataIn (Text As String, EOL As Integer)
If EOL Then Text = Text & Chr$(13) & Chr$(10)
tResponse.SelStart = Len(tResponse.Text)
tResponse.SelText = Text
End Sub

If the EOL parameter has the value True , it indicates that the data was followed by an end-of-line character (an ASCII 10) and causes the program to start a new line in the sidebar . The insertion point is moved to the end of the text, and the new text is added to the contents of the box.

When the incoming data stops, the user can manipulate the scrolling text box to review the hurricane information ( see the screen ). No code is required to provide this feature, since this functionality is already built into the text-box control. Another control, a Visual Basic timer, causes the process to repeat every 15 minutes. The button at the top of the window starts the polling process again and lets the user get an instant report.

All Done

That's all there is to it. Development tools like Visual Basic make building the GUI side of Internet applications a snap; devSoft's IPPort VBX takes care of the rest. Armed with some easy-to-use tools and some basic knowledge of the Internet, you can sit down and quickly write nontrivial programs for the Net.

---

OSI Layers

Physical       Network and communica
tions hardware

Data link      Reliable data transmission across physical link

Network        Establish and maintain connections across networks

Transport      Transfer of data between endpoints

Session        Establish and maintain connections between applications

Presentation   Transform data to provide application interface

Application    Actual services for users of the OSI environment

---

Hurricane Tracker

screen_link (28 Kbytes)

---

Brett Glass ( rogue@well.com ), a 15-year resident of the Internet, is a writer, computer consultant, and teacher in Laramie, Wyoming.