Networks are complex organizational forms. They bring into association discrete entities or nodes, allowing these nodes to connect to other nodes and indeed to other networks. Networks exist in the world in a vast variety of forms and in even more contexts: political, social, biological, and otherwise. While artists have used networks in many ways-from postal networks used to disseminate work, to informal networks of artistic collaborators and larger aesthetic movements-this section looks specifically at a single instance of network technology, the Internet, and how artists have incorporated this technology into their work. There are two general trends: art-making where the Internet is used as a tool for quick and easy dissemination of the work, and art-making where the Internet is the actual medium of the work. These two trends are not mutually exclusive, however. Some of the most interesting online work weaves the two techniques together into exciting new forms that surpass the affordances of either technique.

The Internet and the arts

“In December 1995, Vuk Cosic got a message . . .” or so begins the tale of how “net.art,” the niche art movement concerned with making art in and of the Internet, got its start and its name. As Alexei Shulgin explains in a posting to the Nettime email list two years later, Cosic, a Slovenian artist, received an email posted from an anonymous mailer. Apparently mangled in transit, the message was barely legible. “The only fragment of it that made any sense looked something like: […] J8~g#|\;Net. Art{-^s1 […].”¹

Anonymous, accidental, glitchy, and slightly apocryphal-these are all distinctive characteristics of the net.art style, as seen in web-based work from Cosic, Shulgin, Olia Lialina, Jodi, Heath Bunting, and many others. As Marina Grzinic writes, the “delays in transmission-time, busy signals from service providers, [and] crashing web browsers” contributed greatly to the way artists envisioned the aesthetic potential of the web, a tendency that ran counter to the prevailing wisdom at the time of dot-com go, go, go.² Indeed many unsuspecting users assume that Jodi's web-based and downloadable software projects have as their primary goal the immediate infection and ruin of one's personal computer. (Upon greater scrutiny, it must be granted that this is only a secondary goal.) Perhaps peaking in 1998 with the absurd, anarchist experiments shoveled out on the 7-11 email list-spoofs and shenanigans were par for the course due to the fact that the list administration tool, including subscriptions, header and footer variables, and moderation rules, was world read-writable by any web surfer—the net.art movement is today viewable in captivity in such catchall publications as the hundred-contributor-strong anthology Readme!, edited in several cities simultaneously and published by Autonomedia in 1999; the equally ecumenical anthology NTNTNT that emerged from CalArts in 2003; or Tilman Baumgärtel’s two volumes of interviews, net.art (1999) and net.art 2.0 (2001).

At the same time, buoyed by the dynamism of programming environments like Java and Flash, artists and designers began making online work that not only was “in and of” the Internet, but leveraged the net as a tool for quick and easy dissemination of executable code, both browser-based and otherwise. John Maeda created a number of sketches and games dating from the mid-1990s, including a series of interactive calendars using visual motifs borrowed from both nature and mathematics. Joshua Davis also emerged as an important figure through his online works Praystation and Once-Upon-A-Forest. Like Maeda, Davis fused algorithmic drawing techniques with an organic sense of composition.

It is worth recalling the profound sense of optimism and liberation that the web brought to art and culture in the mid-1990s. All of a sudden, tattooed skaters like Davis were being shuttled around the globe to speak to bespectacled venture capitalists about the possibilities of networking, generative code, and open software projects. And bespectacled philosophers like Geert Lovink were being shuttled around the globe to speak to tattooed skaters about-what else—the possibilities of networking, generative code, and open software projects. Everything was topsy-turvy. Even the net.art movement, which was in part influenced by Lovink’s suspicion of all things “wired” and Californian, was nonetheless propelled by the utopian promise of networks, no matter that sometimes those networks had to be slashed and hacked in the process. Networks have, for several decades, acted as tonics for and inoculations against all things centralized and authoritarian, be they Paul Baran’s 1964 schematics for routing around both the AT&T/Bell national telephone network and the then-impending sorties of Soviet ICBMs; or the grassroots networks of the 1960s new social movements, which would later gain the status of art in Deleuze and Guattari’s emblematic literary concept of the “rhizome,” quite literally a grassroots model of networked being; or indeed the much earlier and oft-cited remarks from Bertolt Brecht on the early revolutionary potential of radio networks (reprised, famously, in Hans Magnus Enzensberger’s 1974 essay on new media, “Constituents for a Theory of the Media”). In other words, the arrival of the web in the middle to late 1990s generated much excitement in both art and culture, for it seemed like a harbinger for the coming of some new and quite possibly revolutionary mode of social interaction. Or, as Cosic said once, with typical bravado, “all art to now has been merely a substitute for the Internet.”

It is also helpful to contextualize these remarks through reference to the different software practices of various artists and movements. Each software environment is a distinct medium. Each grants particular aesthetic affordances to the artist and diminishes others. Each comes with a number of side effects that may be accentuated or avoided, given the proclivities of the artist. So, while acknowledging that digital artists’ tools and materials tend to vary widely, it is perhaps helpful to observe that the net.art scene (Bunting, Shulgin, Lialina, Jodi, et al.), particularly during the period 1995–2000, coded primarily in browser-based markup languages such as HTML, with the addition of Javascript for the execution of basic algorithms. A stripped-down, “text only” format was distinctive of this period. One gag used by a number of different artists was not to have a proper homepage at all, but instead to use Apache’s default directory index of files and folders. The stripped-down approach did not always deliver simplicity to the user, however, as in the case of Jodi’s early homepage (now archived at http://wwwwwwwww.jodi.org) in which they neglected a crucial pre tag and then, in an apparent attempt to overcompensate for the first glitch, encircled the page in a blink tag that was no less prickly on the eyes than the missing pre tag is disorienting. The blinking page throbbed obscenely in the browser window, one glitch thus compounding the other. Created as an unauthorized addition to HTML by Netscape Navigator, the blink tag essentially vanished from the Internet as Internet Explorer became more dominant in the late 1990s. Today, the Jodi page doesn’t blink. One wonders which exactly is the work: the op-art strobe effect that appeared in the Netscape browser window during the years when people used Netscape, or the HTML source still online today in which the work is “explained” to any sleuth willing to trace the narrative of markup tags missing and misplaced?

While artists had used fixed-width ASCII fonts and ANSI characters as design elements long before the popularization of the web in the mid-1990s, it was the creation of HTML in 1993 (synchronized with its use in the newly invented web servers and web browsers like Netscape) that transformed the Internet into a space for the visual arts. HTML established itself quickly as the most influential mark-up language and graphic design protocol for two reasons: first, the text-only nature of HTML made it low-bandwidth-friendly during a time when most users connected via modems and phone lines; and second, HTML is a protocol, meaning that it acts as a common denominator (the blink tag notwithstanding) bridging a wide variety of dissimilar technical platforms. But, as seen in the work of Davis, which gravitates toward Flash but also includes web, print, and video, one must not overemphasize HTML as an aesthetic medium. During this same period, the network delivery of executable code (Java applets, Flash, Shockwave, and so on) also became more and more exciting as a medium for art-making, as did CUSeeMe, web radio, video, and other streaming content that operates outside of the normal bounds of the browser frame. John Simon’s 1997 Every Icon was written as a Java applet and therefore easily deliverable online as executable code. In what Lev Manovich has dubbed “Generation Flash,” a whole new community sprang up, involving artists like Yugo Nakamura, Matt Owens, and James Paterson and intersecting with both dot-com startups like i|o 360° and Razorfish (or the artist’s own design shops) and indie youth culture. Their medium is not solely the text-only markup codes of HTML but also the more sophisticated Macromedia languages (ActionScript and Lingo) as well as Javascript, Java, and server-side languages like Perl and PHP.

Internet concepts

In order to understand how online works are made and viewed, it will be useful to address a number of key concepts in the area of computer networking. A computer network consists of two or more machines connected via a data link. If a networked computer acts primarily as a source of data, it is called a server. A server typically has a fixed address, is online continuously, and functions as a repository for files which are transmitted back to any other computers on the network that request them. If a networked computer acts primarily as a solicitor of information, it is called a client. For example, in checking one’s email, one acts as a client. Likewise, the machine where the email is stored (the machine named after the @ sign in the email address) acts as a server. These terms are flexible; a machine may act as a server in one context and a client in another.

Any machine connected to the Internet, be it client or server, is obligated to have an address. On the Internet, these addresses are called IP addresses and come in the form 123.45.67.89. (A new addressing standard is currently being rolled out that makes the addresses slightly longer.) Since IP addresses change from time to time and are difficult to remember, a system of natural-language shortcuts called the Domain Name System (DNS) allows IP addresses to be substituted by domain names such as “processing.org” or “google.com.” In a web address the word immediately preceding the domain name is the host name; for web servers it is customary to name the host machine “www” after the World Wide Web. But this is only customary. In fact, a web server’s host name can be most anything at all.

One of the main ways in which visual artists have used the Internet in their work is to conceive of the network as one giant database, an input stream that may be spidered, scanned, and parsed using automated clients. This is an artistic methodology that acknowledges the fundamental mutability of data (what programmers call “casting” a variable from one data type to another) and uses various data sources as input streams to power animations, to populate arrays of numbers with pseudo-random values, to track behavior, or quite simply for “content.” Lisa Jevbratt’s work 1:1 does this through the premise that every IP address might be represented by a single pixel. Her work scans the IP address namespace, number by number, pinging each address to determine whether a machine is online at that location. The results are visualized as pixels in a gigantic bitmap that, quite literally, represents the entire Internet (or at least all those machines with fixed IP addresses). In a very different way, Mark Napier’s two works Shredder and Digital Landfill rely on a seemingly endless influx of online data, rearranging and overlaying source material in ways unintended by the original creators. Works like Carnivore (more on this below) and Minitasking approach the network itself as a data source, the former tapping into real-time web traffic, and the latter tapping into real-time traffic on the Gnutella peer-to-peer network. Earlier works such as >I/O/D 4 (known as “The Webstalker”), or Jodi’s Wrongbrowser series of alternative web browsers also illustrate this approach, that the network itself is the art. All of these works automate the process of grabbing data from the Internet and manipulating it in some way. One of the most common types is a web client, a piece of software that automates the process of requesting and receiving remote files on the World Wide Web.

Example 1: Web client

Processing’s Net library includes ready-made classes for both servers and clients. In order to fetch a page from the web, first one creates a client and connects to the address of the remote server. Using a simple call-and-response technique, the client requests the file and the file is returned by the server. This call-and-response is defined by a protocol called Hypertext Transfer Protocol (HTTP). HTTP consists of a handful of simple commands that are used to describe the state of the server and client, to request files, and to post data back to the server if necessary. The most basic HTTP command is GET. This command is similar to filling out a book request form in a library: the client requests a file by name, the server “gets” that file, and returns it to the client. HTTP also includes a number of response codes to indicate that the file was found successfully, or to indicate if any errors were encountered (for example, if the requested file doesn’t exist). The command GET/HTTP/1.0\n means that the client is requesting the default file in the root web directory (/) and that the client is able to communicate using HTTP version 1.0. The trailing \n is the newline character, or roughly equivalent to hitting the return key. If the default file exists, the server transmits it back to the client.

While most computers have only a single Ethernet port (or wireless connection), the entire connectivity of each machine is able to sustain more connections than a single input or output, because the concept of a port is abstracted into software and the functionality of the port is thus duplicated many times over. In this way, each networked computer is able to multitask its single network connection across scores of different connections (there are 1,024 well-known ports, and 65,535 ports in all). Thus ports allow a networked computer to communicate simultaneously on a large number of “channels” without blocking other channels or impeding the data flow of applications. For example, it is possible to read email and surf the web simultaneously because email arrives through one port while websites use another. The union of IP address and port number (example: 123.45.67.89:80) is called a socket. Socket connections are the bread and butter of networking.

// 1: A simple web client using HTTP

import processing.net.*;

Client c;
String data;

void setup() {
  size(200, 200);
  background(50);
  fill(200);
  c = new Client(this, "www.ucla.edu", 80);  // Connect to server on port 80
  c.write("GET / HTTP/1.0\n");  // Use the HTTP "GET" command to ask for a webpage
  c.write("Host: www.ucla.edu\n\n"); // Tell the server for which domain you are making the request
}

void draw() {
  if (c.available() > 0) {    // If there's incoming data from the client...
    data += c.readString();   // ...then grab it and print it
    println(data);
  }
}

Example 2: Shared drawing canvas

Using the Processing Net library, it is possible to create a simple server. The example shows a server that shares a drawing canvas between two computers. In order to open a socket connection, a server must select a port on which to listen for incoming clients and through which to communicate. Although any port number may be used, it is best practice to avoid using port numbers already assigned to other network applications and protocols. Once the socket is established, a client may connect to the server and send or receive commands and data.

Paired with this server, the Processing Client class is instantiated by specifying a remote address and port number to which the socket connection should be made. Once the connection is made, the client may read (or write) data to the server. Because clients and servers are two sides of the same coin, the code examples are nearly identical for both. For this example, current and previous mouse coordinates are sent between client and server several times per second.

// 2A: Shared drawing canvas (Server)

import processing.net.*;

Server s;
Client c;
String input;
int data[];

void setup() {
  size(450, 255);
  background(204);
  stroke(0);
  frameRate(5); // Slow it down a little
  s = new Server(this, 12345);  // Start a simple server on a port
}
void draw() {
  if (mousePressed == true) {
    // Draw our line
    stroke(255);
    line(pmouseX, pmouseY, mouseX, mouseY);
    // Send mouse coords to other person
    s.write(pmouseX + " " + pmouseY + " " + mouseX + " " + mouseY + "\n");
  }

  // Receive data from client
  c = s.available();
  if (c != null) {
    input = c.readString();
    input = input.substring(0, input.indexOf("\n"));  // Only up to the newline
    data = int(split(input, ' '));  // Split values into an array
    // Draw line using received coords
    stroke(0);
    line(data[0], data[1], data[2], data[3]);
  }
}

// 2B: Shared drawing canvas (Client)

import processing.net.*;

Client c;
String input;
int data[];

void setup() {
  size(450, 255);
  background(204);
  stroke(0);
  frameRate(5); // Slow it down a little
  // Connect to the server’s IP address and port­
  c = new Client(this, "127.0.0.1", 12345); // Replace with your server’s IP and port
}

void draw() {
  if (mousePressed == true) {
    // Draw our line
    stroke(255);
    line(pmouseX, pmouseY, mouseX, mouseY);
    // Send mouse coords to other person
    c.write(pmouseX + " " + pmouseY + " " + mouseX + " " + mouseY + "\n");
  }

  // Receive data from server
  if (c.available() > 0) {
    input = c.readString();
    input = input.substring(0,input.indexOf("\n"));  // Only up to the newline
    data = int(split(input, ' '));  // Split values into an array
    // Draw line using received coords
    stroke(0);
    line(data[0], data[1], data[2], data[3]);
  }
}

Example 3: Carnivore Client

If a lower-level examination of the flows of data networks is desired, the Carnivore library for Processing allows the programmer to run a packet sniffer from within the Processing environment. A packet sniffer is any application that is able to indiscriminately eavesdrop on data traffic traveling through a local area network (LAN), even traffic not addressed to the machine running the sniffer. While this might sound unorthodox, and indeed a machine running a sniffer is described as being in “promiscuous mode,” packet-sniffing technologies are as ubiquitous as the Internet itself and just as old. Systems administrators use packet sniffers to troubleshoot networking bugs. All Macintosh machines ship with the packet sniffer tcpdump preinstalled, while Windows and Linux users have an assortment of free sniffers (including tcpdump and its variants) to choose from. The Carnivore library for Processing merely simplifies the act of sniffing packets, making real-time traffic monitoring easy to implement for any artist wishing to do so. Packets captured via Carnivore can be visualized in map form, parsed for keywords, or simply used for any type of algorithm that requires a steady stream of nonrandom event triggers.

/**
 * 3: Carnivore Client
 *
 * This example requires the Carnivore Library for Processing (http://r-s-g.org/carnivore)
 * On Windows, first install winpcap (http://winpcap.org)
 * On Mac OS X, first open a Terminal and execute this commmand: sudo chmod 777 /dev/bpf*
 * (This must be done each time you reboot your Mac)
 */

import java.util.Iterator;
import org.rsg.carnivore.*;
import org.rsg.carnivore.net.*;
import org.rsg.lib.Log;

HashMap nodes = new HashMap();
float startDiameter = 100.0;
float shrinkSpeed = 0.97;
int splitter, x, y;
CarnivoreP5 c;

void setup(){
  size(800, 600);
  ellipseMode(CENTER);

  Log.setDebug(true); // Uncomment this for verbose mode
  c = new CarnivoreP5(this);
  //c.setVolumeLimit(4);
}

void draw() {
  background(255);
  drawNodes();
}

// Iterate through each node
synchronized void drawNodes() {
  Iterator it = nodes.keySet().iterator();
  while (it.hasNext()){
    String ip = (String)it.next();
    float d = float(nodes.get(ip).toString());

    // Use last two IP address bytes for x/y coords

    String ip_as_array[] = split(ip, '.');
    x = int(ip_as_array[2]) * width / 255; // Scale to applet size
    y = int(ip_as_array[3]) * height / 255; // Scale to applet size

    // Draw the node
    stroke(0);
    fill(color(100, 200));  // Rim
    ellipse(x, y, d, d);    // Node circle
    noStroke();
    fill(color(100, 50));   // Halo
    ellipse(x, y, d + 20, d + 20);

    // Draw the text
    fill(0);
    text(ip, x, y);

    // Shrink the nodes a little
    if(d > 50) {
        nodes.put(ip, str(d * shrinkSpeed));
    }
  }
}

// Called each time a new packet arrives
synchronized void packetEvent(CarnivorePacket packet){
  println("[PDE] packetEvent: " + packet);

  // Remember these nodes in our hash map
  nodes.put(packet.receiverAddress.toString(), str(startDiameter));
  nodes.put(packet.senderAddress.toString(), str(startDiameter));
}

Internet protocols

Carnivore is a good stepping stone into the final area of computer networking discussed here: the Internet protocols. A protocol is a technological standard. The Internet protocols are a series of documents that describe how to implement standard Internet technologies such as data routing, handshaking between two machines, network addressing, and many other technologies. Two protocols have already been discussed-HTML, which is the language protocol for hypertext layout and design; and HTTP, which is the protocol for accessing web-accessible files—but there are a few other protocols worth discussing in this context.

Protocols are abstract concepts, but they are also quite material and manifest themselves in the form of structured data headers that prepend and encapsulate all content traveling through the Internet. For example, in order for a typical HTML page to travel from server to client, the page is prepended by an HTTP header (a few lines of text similar to the GET command referenced previously). This glob of data is itself prepended by two additional headers, first a Transmission Control Protocol (TCP) header and next by an Internet Protocol (IP) header. Upon arrival at its destination, the message is unwrapped: the IP header is removed, followed by the TCP header, and finally the HTTP header is removed to reveal the original HTML page. All of this is done in the blink of an eye. All headers contain useful information about the packet. But perhaps the four most useful pieces of information are the sender IP address, receiver IP address, sender port, and receiver port. These four pieces are significant because they indicate the network addresses of the machines in question, plus, via a reverse lookup of the port numbers, the type of data being transferred (port 80 indicating web data, port 23 indicating a Telnet connection, and so on). See the /etc/services file on any Macintosh, Linux, or UNIX machine, or browse IANA’s registry for a complete listing of port numbers. The addresses are contained in the IP header from byte 12 to byte 29 (counting from 0), while the ports are contained in bytes zero through three of the TCP header.

The two elements of the socket connection (IP address and port) are separated into two different protocols because of the different nature of IP and TCP. The IP protocol is concerned with routing data from one place to another and hence requires having an IP address in order to route correctly but cares little about the type of data in its payload. TCP is concerned with establishing a virtual circuit between server and client and thus requires slightly more information about the type of Internet communication being attempted. IP and TCP work so closely together that they are often described in one breath as the “TCP/IP suite.”

While most data on the Internet relies on the TCP/IP suite to get around, certain forms of networked communication are better suited to the UDP/IP combination. User Datagram Protocol (UDP) has a much leaner implementation than TCP, and while it therefore sacrifices many of the features of TCP, it is nevertheless useful for stateless data connections and connections that require a high throughput of packets per second, such as online games.

Network tools

There are a number of existing network tools that a programmer may use beyond the Processing environment. Carnivore and tcpdump, two different types of packet sniffers that allow one to receive LAN packets in real time, have already been mentioned. The process of scanning networks for available hosts, called network discovery, is also possible using port scanner tools such as Nmap. These tools use a variety of methods for looping through a numerical set of IP addresses (example: 192.168.1.x where x is incremented from 0 to 255), testing to see if a machine responds at that address. Then, if a machine is known to be online, the port scanner is used to loop through a range of ports on the machine (example: 192.168.1.1:x where x is a port number incremented from 1 to 1024) in order to determine which ports are open, thereby determining which application services are available. Port scans can also be used to obtain “fingerprints” for remote machines, which aid in the identification of the machine’s current operating system, type, and version information for known application services.

Perhaps the most significant advance in popular networking since the emergence of the web in the mid-1990s was the development of peer-to-peer systems like Gnutella or BitTorrent. Coming on the heels of Napster, Gnutella fully distributed the process of file sharing and transfer, but also fully distributed the network’s search algorithm, a detail that had created bottlenecks (not to mention legal liabilities) for the more centralized Napster. With a distributed search algorithm, search queries hopscotch from node to node, just like the “hot potato” method used in IP routing; they do not pass through any centralized server. The Gnutella protocol has been implemented in dozens of peer-to-peer applications.

Yet more recently Gnutella has been superseded by systems like BitTorrent, a peer-to-peer application that allows file transfers to happen simultaneously between large numbers of users. BitTorrent has gained wide popularity for its increased efficiencies, particularly for transfers of large files such as video and software.

Many software projects requiring networked audio have come to rely on the Open Sound Control (OSC) protocol. OSC is a protocol for communication between multimedia devices such as computers and synthesizers. OSC has been integrated into SuperCollider and Max/MSP and has been ported to most modern languages including Perl and Java. Andreas Schlegel’s “oscP5” is an OSC extension library for Processing.

The Internet has become more peer-oriented in other ways too, not simply through file sharing but also through friend communities and other kinds of social interaction. Web 2.0 platforms like Facebook, Twitter, or YouTube allow groups of people to network with each other, whether it be a small group of five or ten, or a larger group of several thousands. While the more traditional client-server model relied on a clear distinction between information providers and information consumers, newer systems have disrupted some of the old hierarchies, allowing networked users to act as both producers and consumers of content. Such systems thus rely heavily on user-generated content and expect a higher amount of participation and interaction from their user base.

Conclusion

Programmers are often required to consider interconnections between webs of objects and events. Because of this, programming for networks is a natural extension of programming for a single machine. Classes send messages to other classes just like hosts send messages to other hosts. An object has an interface, and so does an Ethernet adapter. The algorithmic construction of entities in dialogue-pixels, bits, frames, nodes-is central to what Processing is all about. Networking these entities by moving some of them to one machine and some to another is but a small additional step. What is required, however, is a knowledge of the various standards and techniques at play when bona fide networking takes place.

Historically, there have been two basic strands of networked art: art where the network is used as the actual medium of art-making, or art where the network is used as the transportation medium for dissemination of the work. The former might be understood as art of the Internet, while the latter as art for the Internet. The goal of this text has been to introduce some of the basic conditions, both technological and aesthetic, for making networked art, in the hopes that entirely new techniques and approaches will spring forth in the future as both strands blend together into exciting new forms.

Notes