netcat: literally `cat through the network`   
=================================================

You might have heard somebody saying that netcat(1) is the "network
swiss-army knife". You bet they definitely meant that. 

It is quite easy to explain what netcat(1) (or nc(1)) does: it simply
connects its standard input/output to a TCP or UDP socket, effectively 
allowing to communicate with remote hosts from the command line. 

For instance, you can use nc(1) to retrieve and visualise a gopher
resource by using something like:

  $ printf "/backstory\r\n" | nc zaibatsu.circumlunar.space 70 | less

The line above will show the Circumlunar Space "backstory" in less(1).
What happens is that nc(1) is connecting to `zaibatsu.circumlunar.space`
on port 70 (what a surprise!), and writing on the socket the string
`/backstory\r\n`, that is the gopher way to request a given file. Then,
nc(1) will spit on the standard output whatever it received from the
other side of the connected socket. In this case, the stdout of nc(1)
was piped into the stdin of less(1). Easy, right? 

Similarly, you can retrieve the home webpage at tilde.town (and all its
headers) by using:

  $ printf "GET / HTTP/1.0\n\n" | nc tilde.town 80
  
The cool aspect of nc(1) is that it can also act as a "server", meaning
that it can bind to a TCP/UDP port and wait for incoming connections.
When a "client" connects on that port, nc(1) will simply send over the
socket whatever it gets on stdin (on the server side) and dump on stdout
whatever it receives from the remote "client". This makes nc(1) an ideal
tool to create ephemeral servers. For instance, for remote backups. 

Imagine you want to backup your gopher/ folder on `my_host` to a tar.gz
file on `backup_server`,and that `backup_server` has IP 10.20.30.40. You
would first run on `backup_server`:

  $ netcat -l 10.20.30.40 8765 > backup.tar.gz

This will instruct nc(1) to bind to port 8765 on IP 10.20.30.40 and wait
for connections. Any stuff received by nc(1) on that connection will
then be put in the file `backup.tar.gz`.

After that, you would run on `my_host`:

  $ find gopher/ | pax -wd | gzip -c | nc 10.20.30.40 8765 

This command will create a tar file (using the POSIX tool pax(1)), gzip
it, and send it through nc(1) to whatever is listening on port 8765 on
IP 10.20.30.40. Wait a minute: that's the IP of `backup_server`, and our
other nc(1) process is just listening on port 8765 on that IP! So after
a little while you should see a file called `backup.tar.gz` on
`backup_server` which contains a backup of your gopherhole on `my_host`. 

We have used the `pax(1)` tool here just because that's the POSIX way of
dealing with archive files (in both tar(1) and cpio(1) formats). YMMV.

 -+-+-+-
nc(1)   was originally developed by hobbit@avian.org in the early '90s
less(1) was originally developed by M. Nudelman as a replacement for 
        more(1)
find(1) was introduced in UNIXv1
gzip(1) was originally developed by J-L Gailly and M. Adler in 1992
        as part of the GNU Project
pax(1)  was introduced in 4.4BSD, as is part of the POSIX specification