VB and the Internet

Beauty and the beast. (you decide which is which)

Internet refresher

The Internet is a loose combination of Local area networks. It is a combination of hardware, software, and protocols. The Internet is supposed to encourage communication across geographic distance as well as multiple platforms, operating systems, and hardware devices. It is based on the client - server model

Client - server

Machines and software are loosely grouped as clients or servers. Server machines are those used by developers, or producers of internet materials. A server machine is typically a large, expensive computer which has a large, expensive full - time connection to the rest of the net, and it (supposedly) is never turned off.

Server software are the programs that run on a server machine. These programs 'dole out' information. If you want to post a web page, send or receive email, or do nearly anything else, your work will eventually go through a server or two. Most users never deal with server software directly, they rely on client programs to do this for them

Client software are the programs that users directly control. These programs 'know how' to connect to a server and conduct a transaction with it. Web browsers, email programs, and FTP clients are all examples of client software.

Microsoft and the Internet

By the mid 90's, Microsoft was conspicuously uninvolved in the Internet world. Almost all servers were running the UNIX operating system, which Microsoft did not support at all (and still barely acknowledges). Most clients had been designed by other parties such as Netscape and Eudora.

Obviously, this was not a situation the Bill and his friends could tolerate, so Microsoft began aggressively positioning themselves into the Internet world. Visual Basic is a prominent part of the Microsoft strategy, and it is not surprising that it is used in a number of ways as a part of Microsoft's response to the Internet.

Visual basic is chiefly utilized in three different ways as an Internet tool:

We can write clients in visual basic, We can use visual basic INSIDE a client, to enhance its behavior, or we can use a form of VB on the server to write or enhance the server.

We will examine all of these concepts briefly.

Writing low level clients with winsock

sockets and protocols

The Internet uses something called a socket as a communication tool. Essentially, servers open up sockets, which are like little ports which client machines can hook up to. The server is always running, waiting for connections from clients. As soon as a client connects, the server can communicate with it through its socket. The client also creates a socket. When it is created, it looks for a specific server and attempts to connect to it. Both the client and the server use the socket as a port to talk to the other program.

Since one server machine might be simultaneously running several server programs, we use a port to distinguish which server program we want. In addition, various server programs will have different 'mini-languages' they will use to communicate. These mini-languages are the protocols. TCPIP, SMTP, POP, FTP, and HTTP are all examples of protocols. These are simply syntaxes for communication between various types of clients and servers. When we connect to a specific port, we are generally setting ourselves up to talk with a particular protocol. The client and server must expect to be on the same protocol, or there will be trouble.

An example: smtp on the unix command line

To make this clearer, here is an example of a UNIX command line interchange. What I'm going to do here is connect to klingon (a mail server, among other things).
First, I'll provide a transcript of the conversation, then I'll explain what was happening. (I added line numbers for clarity)

1. ds9{aharris}18: telnet klingon 25
2. Trying 134.68.140.1...
3. Connected to klingon.
4. Escape character is '^]'.
5. 220 klingon.cs.iupui.edu ESMTP Sendmail 8.9.1/8.9.1; Thu, 15 Apr 1999 12:30:42 )
6. HELO babbage
7. 250 klingon.cs.iupui.edu Hello ds9 [134.68.140.211], pleased to meet you
8. MAIL FROM: aharris@cs.iupui.edu
9. 250 aharris@cs.iupui.edu... Sender ok
10. RCPT TO: aharris@cs.iupui.edu
11. 250 aharris@cs.iupui.edu... Recipient ok
12. DATA
13. 354 Enter mail, end with "." on a line by itself
14. subject: It works!!!
15. Whoo Hoo!!!
16. .
17. 250 MAA07093 Message accepted for delivery
18. QUIT
19. 221 klingon.cs.iupui.edu closing connection
20. Connection closed by foreign host.

In line 1, I set up a connection to klingon port 25. Telnet will actually provide the socket for me automatically. (stupid unix trick, it's not important if you don't understand it completely) The important thing is that I set up a connection to klingon, and I told it I want port 25, which is the SMTP server. (I had to look that up)

In lines 2-5, sendmail replied to me that it had recieved a connection.

In line 6, I sent a HELLO message. SMTP has its own protocol and commands, which you can learn by logging on and invoking the HELP command. Most SMTP commands are four characters long, which explains why it is HELO rather than HELLO. SMTP is not case sensitive, but most programers use all upperCase. The parameter is the domain name. I sent the domain of my desktop machine. It just needs to be a legal domain that the server recognizes.

Line 7 was a response telling me the server knows who I am.

In line 8, I set up the address of the SENDER. Right now, it is me, but you would frequently use this protocol to create a mail client, so this might come from the user. It has to be a legal email address.

Line 9 is an acknowledgement of the sender.

Line 10 establishes who the email will go to.

Line 11 acknowledges that the recipient is also OK.

Line 12 is where I start defining the data to send..

Line 13 is instructions on how to send and end the data
14 and 15 are actual data. Note how the subject header is done

Line 16 is an 'end of data' signal

In line 17, I get a (terse) message which implies (but doesn't guarantee) that everything worked

In line 18, I tell the server I want to quit

19 and 20 are 'goodbye' messages.

Let's do it in VB with winsock!

Winsock is the name of a special socket object provided by VB6. You can add it to the toolbox and drop it on your form. It is not visible at run-time, but has a number of interesting properties, methods, and events.

I made a form with a winsock on it, a couple of textboxes, and a command button. For the output textbox, I used an RTB rather than the traditional textbox, because it handles carriage returns better, but everything else is pretty much the same. Here's the VB code:

Private Sub cmdOK_Click()
Winsock1.SendData txtInput.Text + vbCrLf
txtInput.Text = ""
txtInput.SetFocus
End Sub

Private Sub Form_Load()
Winsock1.RemoteHost = "klingon.cs.iupui.edu"
Winsock1.RemotePort = 25
Winsock1.Connect
End Sub

Private Sub Winsock1_Connect()
MsgBox "I got connected!"
End Sub

Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
Dim reply As String
Winsock1.GetData reply, vbString
MsgBox (reply)
rtbOutput.Text = rtbOutput.Text + reply
End Sub

In form_load, I was interested in ensuring that the socket was properly connected to the server. I set the remoteHost and remotePort properties of the winsock to appropriate values, then ran the winsock's connect method.

To ensure that a connection happened, I put some code in the winsock's connect EVENT (different than the method). I simply placed code announcing that a connection had occured. This is very handy when debugging.

Winsock also has a dataArrival event, which is triggered whenever data is recieved by the socket. As you can see, I simply used the getData method to grab the response. GetData takes two parameters, a variable to contain the answer, and the type of that variable. The variable type is theoretically optional, but the program would not work for me when I left it out. (vbString is a built in constant representing a string variable type). Once I had a reply value, I added it to the output text box. This event will occur every time data comes in. For more complex protocols, we would probably need to parse out the response and use it to formulate the next message.

In cmdOK_click, I took whatever value was in the textbox, and sent it to the socket. That will send it to the server. I also did some cleanup, to make it easier to send multiple lines of text.

The program is now a low-level interface to the sendmail server. Obviously this would not be much help to a user who did not understand SMTP protocol, but you can see from this example how we could build a more user-friendly interface.

The Internet Transfer control

VB provides some much higher - level controls which can be extremely handy as well. If you want to retrieve text data stored on the web somewhere, or a file at an FTP site, the Inet control can make it a trivial prospect. Once you have it on your form, the OpenURL method will return back the contents of the site as a big string.

For example, this code returns back the source code of my main page:

Private Sub Form_Load()
rtbOutput.Text = Inet1.OpenURL("http://www.cs.iupui.edu/~aharris/index.html")
End Sub

Obviously, this is of limited utility, but many webmasters also place data on web pages. The following call returns back a data file of grades from an old class:

Private Sub Form_Load()
rtbOutput.Text = Inet1.OpenURL("http://www.cs.iupui.edu/~aharris/cgi-bin/g201F97.dat")
End Sub

It would not be difficult to see how useful this could be... We could write some code that would do ask for the user's userID, then look for that ID in the code, and return back only their data on a VB form.

Obviously this is going to be read-only, but it is an easy way to get at data stored on the web.

Such a control is also frequently used to 'preview ' sites to ensure they do not contain 'questionable' words or phrases. Of course, to make such a test work, you would have to have a list of all the terrible words you don't want to see. (Ironically, the 'net nanny' programs are going to contain more filth than any kind of program out there.)

The webBrowser control

Another EXTREMELY handy control for web work is the webBrowser control.

This control is analogous to the data control in the sense that it is essentially the kernal of another Microsoft program.
In this case, the web browser control is the most important parts of IE. IE is just a bunch of user interface attachments surrounding a browser control. The AOL browser is also just a wrapper around a version of the IE web browser control.

Here's a program that uses both the inet and the webBrowser controls. (It is two forms, but all the interesting code is on the main form).

Private Sub cmdOutput_Click()
frmBrowser.Show
frmBrowser!WebBrowser1.Navigate txtURL.Text
End Sub

Private Sub cmdSource_Click()
rtbOutput.Text = Inet1.OpenURL(txtURL.Text)
End Sub

This begs the question: If this is just like the Internet Explorer, why not just create an instance of IE and use it instead?
The answer is that IE sometimes does too much. One of the nicest features of the web browser control is its simplicity. It shows ONLY the page that you send it to, and the user can't directly send it anyplace else. Of course, if this page has links on it, they can be followed, but there is no 'location bar' per se.

This is actually very handy if you want a limited version of a browser, such as one which will limit the sites to which a user can go.

For example, we can modify the above code like this:

Private Sub cmdOutput_Click()
If InStr(rtbOutput.Text, "Computer") Then
    'This is a great page. Let them go
    frmBrowser.Show
    frmBrowser!WebBrowser1.Navigate txtURL.Text
Else
    MsgBox ("Why go there? it isn't about computers...")
End If
End Sub