Datagrams

The

examples you’ve seen so far use the

There’s

a second protocol, called

The

support for datagrams in Java has the same feel as its support for TCP sockets,

but there are significant differences. With datagrams, you put a

A

sends and receives the packets, and the

in

which

is

an array of

.

Since

is an array, you might wonder why the constructor couldn’t figure out the

length of the array on its own. I wondered this, and can only guess that

it’s a throwback to C-style programming, in which of course arrays

can’t tell you how big they are.

You

can reuse a receiving datagram; you don’t have to make a new one each

time. Every time you reuse it, the data in the buffer is overwritten.

The

maximum size of the buffer is restricted only by the allowable datagram packet

size, which limits it to slightly less than 64Kbytes. However, in many

applications you’ll want it to be much smaller, certainly when

you’re sending data. Your chosen packet size depends on what you need for

your particular application.

When

you send a datagram, the

must contain not only the data, but also the Internet address and port where it

will be sent. So the constructor for an outgoing

is:

This

time,

(which is a

array)

already contains the data that you want to send out. The

might be the length of

,

but it can also be shorter, indicating that you want to send only that many

bytes. The other two arguments are the Internet address where the packet is

going and the destination port within that machine.

You

might think that the two constructors create two different objects: one for

receiving datagrams and one for sending them. Good OO design would suggest that

these should be two different classes, rather than one class with different

behavior depending on how you construct the object. This is probably true, but

fortunately the use of

s

is simple enough that you’re not tripped up by the problem, as you can

see in the following example. This example is similar to the

and

example for TCP sockets. Multiple clients will send datagrams to a server,

which will echo them back to the same client that sent the message.

To

simplify the creation of a

from a

and vice-versa, the example begins with a utility class,

,

to do the work for you:

//: Dgram.java
// A utility class to convert back and forth
// Between Strings and DataGramPackets.
import java.net.*;
 
public class Dgram {
  public static DatagramPacket toDatagram(
    String s, InetAddress destIA, int destPort) {
    // Deprecated in Java 1.1, but it works:
    byte[] buf = new byte[s.length() + 1];
    s.getBytes(0, s.length(), buf, 0);
    // The correct Java 1.1 approach, but it's
    // Broken (it truncates the String):
    // byte[] buf = s.getBytes();
    return new DatagramPacket(buf, buf.length,
      destIA, destPort);
  }
  public static String toString(DatagramPacket p){
    // The Java 1.0 approach:
    // return new String(p.getData(), 
    //  0, 0, p.getLength());
    // The Java 1.1 approach:
    return
      new String(p.getData(), 0, p.getLength());
  }
} ///:~ 

The

first method of

takes a

,

an

and a port number and builds a

by copying the contents of the

into a

buffer and passing the buffer into the

constructor. Notice the “+1” in the buffer allocation – this

was necessary to prevent truncation. The

method of

is a special operation that copies the

s

of a

into a

buffer. This method is now deprecated; Java 1.1

The

method shows both the Java 1.0

Here

is the server for the datagram demonstration:

//: ChatterServer.java
// A server that echoes datagrams
import java.net.*;
import java.io.*;
import java.util.*;
 
public class ChatterServer {
  static final int INPORT = 1711;
  private byte[] buf = new byte[1000];
  private DatagramPacket dp =
    new DatagramPacket(buf, buf.length);
  // Can listen & send on the same socket:
  private DatagramSocket socket;
 
  public ChatterServer() {
    try {
      socket = new DatagramSocket(INPORT);
      System.out.println("Server started");
      while(true) {
        // Block until a datagram appears:
        socket.receive(dp);
        String rcvd = Dgram.toString(dp) +
          ", from address: " + dp.getAddress() +
          ", port: " + dp.getPort();
        System.out.println(rcvd);
        String echoString =
          "Echoed: " + rcvd;
        // Extract the address and port from the
        // received datagram to find out where to
        // send it back:
        DatagramPacket echo =
          Dgram.toDatagram(echoString,
            dp.getAddress(), dp.getPort());
        socket.send(echo);
      }
    } catch(SocketException e) {
      System.err.println("Can't open socket");
      System.exit(1);
    } catch(IOException e) {
      System.err.println("Communication error");
      e.printStackTrace();
    }
  }
  public static void main(String[] args) {
    new ChatterServer();
  }
} ///:~ 

The

contains a single

for receiving messages, instead of creating one each time you’re ready to

receive a new message. The single

can be used repeatedly. This

has a port number because this is the server and the client must have an exact

address where it wants to send the datagram. It is given a port number but not

an Internet address because it resides on “this” machine so it

knows what its Internet address is (in this case, the default

).

In the infinite

loop, the

is told to

Now

there’s a bit of a quandary. As you will see, there are potentially many

different Internet addresses and port numbers that the messages might come from

– that is, the clients can reside on any machine. (In this demonstration

they all reside on the

,

but the port number for each client is different.) To send a message back to

the client that originated it, you need to know that client’s Internet

address and port number. Fortunately, this information is conveniently packaged

inside the

To

test this server, here’s a program that makes a number of clients, all of

which fire datagram packets to the server and wait for the server to echo them

back.

//: ChatterClient.java
// Tests the ChatterServer by starting multiple 
// clients, each of which sends datagrams.
import java.lang.Thread;
import java.net.*;
import java.io.*;
 
public class ChatterClient extends Thread {
  // Can listen & send on the same socket:
  private DatagramSocket s;
  private InetAddress hostAddress;
  private byte[] buf = new byte[1000];
  private DatagramPacket dp =
    new DatagramPacket(buf, buf.length);
  private int id;
 
  public ChatterClient(int identifier) {
    id = identifier;
    try {
      // Auto-assign port number:
      s = new DatagramSocket();
      hostAddress =
        InetAddress.getByName("localhost");
    } catch(UnknownHostException e) {
      System.err.println("Cannot find host");
      System.exit(1);
    } catch(SocketException e) {
      System.err.println("Can't open socket");
      e.printStackTrace();
      System.exit(1);
    }
    System.out.println("ChatterClient starting");
  }
  public void run() {
    try {
      for(int i = 0; i < 25; i++) {
        String outMessage = "Client #" +
          id + ", message #" + i;
        // Make and send a datagram:
        s.send(Dgram.toDatagram(outMessage,
          hostAddress,
          ChatterServer.INPORT));
        // Block until it echoes back:
        s.receive(dp);
        // Print out the echoed contents:
        String rcvd = "Client #" + id +
          ", rcvd from " +
          dp.getAddress() + ", " +
          dp.getPort() + ": " +
          Dgram.toString(dp);
        System.out.println(rcvd);
      }
    } catch(IOException e) {
      e.printStackTrace();
      System.exit(1);
    }
  }
  public static void main(String[] args) {
    for(int i = 0; i < 10; i++)
      new ChatterClient(i).start();
  }
} ///:~ 

is created as a

so that multiple clients can be made to bother the server. Here you can see

that the receiving

looks just like the one used for

.

In the constructor, the

is created with no arguments since it doesn’t need to advertise itself as

being at a particular port number. The Internet address used for this socket

will be “this machine” (for the example,

)

and the port number will be automatically assigned, as you will see from the

output. This

,

like the one for the server, will be used both for sending and receiving.

The

is the Internet address of the host machine you want to talk to. The one part

of the program in which you must know an exact Internet address and port number

is the part in which you make the outgoing

.

As is always the case, the host must be at a known address and port number so

that clients can originate conversations with the host.

Each

thread is given a unique identification number (although the port number

automatically assigned to the thread would also provide a unique identifier). In

,

a message

is created that contains the thread’s identification number and the

message number this thread is currently sending. This

is used to create a datagram that is sent to the host at its address; the port

number is taken directly from a constant in

.

Once the message is sent,

blocks until the server replies with an echoing message. All of the information

that’s shipped around with the message allows you to see that what comes

back to this particular thread is derived from the message that originated from

it. In this example, even though UDP is an “unreliable” protocol,

you’ll see that all of the datagrams get where they’re supposed to.

(This will be true for localhost and LAN situations, but you might begin to see

some failures for non-local connections.)

When

you run this program, you’ll see that each of the threads finishes, which

means that each of the datagram packets sent to the server is turned around and

echoed to the correct recipient; otherwise one or more threads would hang,

blocking until their input shows up.

You

might think that the only right way to, for example, transfer a file from one

machine to another is through TCP sockets, since they’re

“reliable.” However, because of the speed of datagrams they can

actually be a better solution. You simply break the file up into packets and

number each packet. The receiving machine takes the packets and reassembles

them; a “header packet” tells the machine how many to expect and

any other important information. If a packet is lost, the receiving machine

sends a datagram back telling the sender to retransmit.

TCP and UDP ports are considered unique. That is, you can simultaneously run a

TCP and UDP server on port 8080 without interference.

|

|