By now we know that Tcl has the functionality to create networked applications. We also know how to build simple client-server communication functionality. However, as with any programming language, being able to plug into existing protocols and communicating using standards that other systems are using is very important. This chapter talks about various standards, how Tcl fits into these (technologies), and how to use Tcl for various types of protocols and data encodings.

We will also talk about communication with users using e-mail. We'll start with sending simple e-mails, followed by learning how to send attachments and multipart types. Using this we'll show how to send and receive e-mails in order to do tasks such as informing users and/or customers. We'll also show how to read e-mails, how to parse them and how simple mechanisms can be built to create an automated e-mail management system.

This chapter also talks about many other protocols that we can use Tcl with. We'll talk about using Lightweight Directory Access Protocol (LDAP) to look up information and/or authenticate users, manually querying host names and time servers.

We'll also show Tcl's comm protocol, which is an RPC mechanism that can be used to invoke remote procedures on same or different machines. We'll show how this can be used both for running commands remotely and locally. We'll also show how we can introduce basic security features and how Tcl can be made to offer limited access to commands.

When writing our applications, it is essential to remember that there are many cases where all network-related functions may throw errors—a network can be down, the server we are communicating with might not be responding or may prevent us from gaining access due to invalid credentials, misconfiguration, or some other reason.

At all stages of writing an application, you should remember to make sure that you handle such errors properly. This is especially important for networked applications. Packages for handling network communication take care of catching such errors. Our application also needs to handle this properly and clean up all resources, inform the user or create a log of such errors—and when it makes sense, the application should retry communication periodically.

Also, when performing checks of any data retrieved from remote systems, we should check if all the conditions are satisfied instead of checking for known problems. For example, we should check if the status is one of the acceptable ones instead of checking if the status is a known error status. Troubleshooting Tcl applications and more recommendations for making applications error prone are described in more details in Chapter 4, Troubleshooting Tcl Applications .

package require dns
set token [dns::resolve "www.google.com"]

dns::wait $token

if {[dns::status $token] != "ok"} {
puts "Problem querying DNS"
exit 1
}

set iplist [dns::address $token]
puts "Google.com IP addresses: [join $iplist ", "]."

dns::cleanup $token

set token [dns::resolve "google.com" -type NS]
dns::wait $token
if {[dns::status $token] == "ok"} {
puts "DNS servers: [join [dns::name $token] ", "]."
}

set token [dns::resolve "gmail.com" -type MX]
dns::wait $token
if {[dns::status $token] == "ok"} {
set mxlist [dns::name $token]
set mxlist [lsort -index 0 -integer $mxlist]
puts "MX servers:
[join $mxlist 
]"
puts "--"
}

set counter [llength $googleiplist]
foreach ip $iplist {
dns::resolve "dns:$ip" 
-type PTR 
-command [list onResolveDone $ip]
}
vwait done

proc onResolveDone {ip token} {
global counter
set name [dns::name $token]
if {[dns::status $token] == "ok"} {
puts "$ip resolves do $name"
} else {
puts "Failed to resolve $ip"
}
dns::cleanup $name
incr counter -1
if {$counter == 0} {exit 0}
}