Telnet using Director

August 29, 2000
by Daniel Cummings

This article is for those familiar with the workings of the MUXtra. Since I do not go into detail on how to set up the commands for a text connection, please refer to Macromedia's site for basic information on this very cool Xtra.

Using the MUXtra, it is possible to establish text-only connections to various Internet ports. Macromedia shows how to make an SMTP client and an IRC client.

Making a Telnet client is a little bit more difficult. This is because in order to establish a connection with a Telnet server you need to agree on a common Telnet "dialect", and in Director the initial dialect agreement has to be done manually.

This article describes how to work the text-only connections using the MU Xtra and establish a Telnet connection with your server. Based on my testing, these techniques also work in Shockwave.

The demo movie allows you to:

Set up the proper network pipes and callbacks for text connections to the net.
Ask the server for Telnet port 23.
Connect with the Telnet server.
Log into the server with your username and password.
Issue a single UNIX command at a time.

Probing a Telnet server

In order to get this to work for those who don't have a Telnet account, I have taken the liberty of establishing a free Telnet BBS account at a place called Mirage. The BBS IP address appears in the demo movie. The proper port number, 23, appears in the port field. Your userid and password on Mirage are:

u:douglass
p:douglass

Someone else's Telnet account

Let's use Mirage as a test to login. We are using this simple Telnet account to make sure that we can make a working connection. The "dialect" steps I alluded to earlier are not necessary because of the way this Telnet server is configured.

Check out the Director 7 sample movie (Mac or PC format) to see the full behavior.

Click the Manual LOGIN button at the top. This uses the MUXtra instance to establish a Telnet connection.

gMUXtra = new(xtra "Multiuser")
serverIP = string(member("serverIP").text)
serverPort = integer(member("port").text)

errCode = gMUXtra.setNetMessageHandler( #DefaultMsg, script "Handlers")
CheckError( errCode )

errCode = gMUXtra.setNetMessageHandler( #FirstConnect, script "Handlers", "connectToNetServer" )
CheckError( errCode )

errCode = gMUXtra.connectToNetServer( "x", "x", serverIP, serverPort, "x", 1)
CheckError( errCode )

As you can see from the code, the IP and port come from the user-editable fields. Then we set up handlers that will deal with the incoming messages. Using setNetMessageHandler, we set up two handlers to capture and process any data that comes back from the remote server. And finally, we connect to the server using connectToNetServer (note the 1 as the last argument, which tells the Xtra that this is a text-only connection, exactly what is needed for Telnet). The "x" strings are there to signify that some arguments are not needed for our purposes; see the MU Xtra docs for more info on these parameters.

If everything is going well, you should see a flurry of text stream up through the "Message Sent from server:" scrolling field. This is happening because the movie set up the #DefaultMessage script to deal with incoming messages and it simply posts them into this field.

When the flurry of text stops, it is time to login. Type the word "douglass" (no quotes) into the Command field and hit the enter/return button to send. Then, type "douglass" again to send your password. Voila! You are now logged in.

If you've ever used a Telnet client before, you'll notice I didn't build all the nice Telnet client features into this movie (pretty columned monospaced text, ascii mapping, commands echoed in line with the messages), so you will wade through a bit of crazy ascii, and a non-standard interface, but we have other, bigger plans for this Telnet shell movie...

Your own Telnet account

OK, now, the fun part. Do you have a telnet account?

No? Sorry, but you might as well stop here: this next sequence will only work if you have a regular Telnet account. Remember, you might have one without knowing. If you are on a dialup ISP, they sometimes offer "shell" accounts. This shell account should allow you to establish a Telnet connection. Talk to your sysadmin.

Yes? Great! For debugging, grab yourself a "proper" Telnet client. If you work in Windows, there is one built in, just choose Run... in the Windows pop-up menu and type telnet. For Macs, Better Telnet is an update to the original NCSA Telnet program.

Login to your account through the proper Telnet client first, just to refresh your memory about the sequence of commands.

When you have done that, logout.

The Telnet protocol is an old one, but it is still used extensively. It was first proposed in 1972 (when I was 3 -- sheesh, the Internet is not so new after all!). For more info refer to http://www.faqs.org/rfcs/rfc318.html. The most common usage of Telnet today is to allow you to login to a distant computer on which you have an account and perform remote functions such as editing and processing of email.

Telnet dialects

The Telnet server protocol specifies a handshaking stage where the client and the server establish what dialect of the Telnet protocol they will use. This is a small hurdle to get over when using/abusing Director as a Telnet client. Every Telnet client you are familiar with hides this dialect step from you, including the proper Telnet client you used in the previous step. Now, when we hack into the MU Xtra, this arcane interchange is revealed, and you must deal with it. Fortunately, I have stripped the dialect step to its bare necessities, and written some code and made buttons that will help you.

The general idea behind this step is that the client and the server agree on what sorts of things they are capable of. If you want to know the specifics of the ASCII code sent during this step in the protocol, check the cast member called telnet negotiation codes in the demo movie.

What we are going to do is step through the negotiation by hand, simply by answering back everything the telnet server sends. Think of it like this. Two people meet in the street. The first says, "I speak Danish," and the other repeats, "I speak Danish." The first says, "I like bread," and the second repeats, "I like bread". The first says, "I like swiss cheese," and the second says, "I like swiss cheese," and the first says, "I like stoneground mustard," and the second says, "I like stoneground mustard," and so on, until it becomes clear that these two people can talk and have a nice sandwich lunch together.

Now, go back to the inline demo movie, edit the IP address field by putting in your server's numerical or alphabetic IP address, and click the Manual LOGIN button.

The scripts are the same as before (see above or in the demo movie scripts), but now we will need to make a few extra steps to establish the connection. The DefaultMsg handler that we set up earlier captures the text from the server and displays it both in the message window via the put command and in the "messageSent" text member:

on DefaultMsg

netMessage = gMUXtra.getNetMessage()
set member("messagesent").text = netMessage.content

--post to message window too
put netmessage.content

  if netMessage.content contains "HTTP" then
    puppetsound "chirp0"
  end if

end

In the sample movie you see a reflect this text button to the left side of the Stage. When the Telnet server begins the "I speak Danish" negotiations, it will post them to the "Message Sent from server:" scrolling field. You simply need to reflect these weird high-ascii characters back to the server. Do that by clicking the "reflect this text" button.

I tried my two Telnet accounts and they each had a different Telnet dialect, but by simply reflecting the text back, I got into both successfully. The first text you see pop into the "reflect text" field should look something like "ÿý(ÿý ÿý#ÿý'". Alien runes? No, actually this says (more or less): Here comes a data bit (ÿ), I can DO (ý) a "cancel" (( = ascii 24). You do not need to understand or interpret these runes; just send them back to the server by clicking the "reflect text" button.

A few iterations of this and you should see a login prompt. Most login prompts look like this: "login:". Now you need to type your username into the "Command" field and hit the enter/return key. The next step is the password step: type your password and hit return.

In my other Telnet projects, I automate this process by testing each bit of text as it comes in. Because the sequence is the same if you always use the same server, you can build a little macro in Lingo.

Notice that this macro just looks for certain strings and reflects them back to the server. Capture your Telnet server's "dialect" messages and make your own macro code that lives in your default message (DefaultMsg) handler.

Fun with UNIX

Are you in? Did you get the welcome message from your remote Telnet account? OK, good. For those of you who know some UNIX, it should be easy to see the power in hooking up Director to a Telnet server. For those of you who don't, you should try first navigating around your account using UNIX commands typed into the Command field. Commands cd and ls are the basic directory navigation commands.

Also, try, "w". This asks the remote machine who else is online right now. Another neat command is "tail -f", which allows you to monitor when a file is updated with new data -- particularly interesting if you can issue a tail -f command on a web server access_log. These logs are commonly located at /usr/local/etc/httpd/logs/.

My favorite use for Telnet in Director is for translating web server hit activity into sound. Director is a great transmuter of media and data. The access_log at http://fargo.itp.tsoa.nyu.edu/ was the first subject of this experiment. In order to complete this entire sequence, which I hope has given you some good ideas of your own, you need to get "read access" to some web server logs. Again, you may already have this privilege, especially if you have a university account. Ask your friendly sysadmin.

In the demo movie, there is an if statement that checks the incoming data to see if it contains "HTTP" -- a sure sign that the data is from an access_log. If it does, it triggers a "chirp" sound. Chirps on hits are nice, but the web server access_log has a whole bunch of interesting data that can be parsed, analyzed and turned into sounds. I have used sound and music to monitor what is going on at my web server -- who is grabbing stuff, how long they stay on a page, what they are grabbing. This is called "Sonification" or "Auralization" and you can find out more about this cool area of research at ICAD.

This telnet technique is useful for things other than listening to Web logs. In fact, the whole world of UNIX is open to you:

w
display who is logged in and what they are doing.

who /var/log/wtmp
The wtmp file contains a record of every login, logout, crash, shutdown and date change since wtmp was last truncated or created. (Visualize the logins of your neighbors.)

talk
roll your own instant messaging (sometimes you must issue a "mesg y" command for this to work)

grep
look for string occurences in files, directories and standard output from commands (data mining on various files)

tail -f /filepath/file
monitor a file and post its changes to the Telnet (shell) window. (Great for monitoring web access_logs!)

ping
test network speed

traceroute
get the path that your internet packets follow

These are just the tip of the iceberg. Happy Telnetting! And be sure to send me any cool techniques you come up with!

Daniel Cummings is the founder and Chief Technologist at Polysense -- a media research and prototyping design firm in San Francisco -- where he investigates Augmented Reality and Polysensory media. Polysense provides device consulting and prototyping services to the technology industry.