MIDP differs somewhat from the J2SE
platform in its support for datagram connections. J2SE has the java.net package. For instance, its
DatagramPacket class defines a datagram. The DatagramSocket class
implements a datagram protocol over a socket connection. These classes don't exist in CLDC/MIDP.
In fact, there's no java.net package
available in CLDC/MIDP. On the other hand, the
CDC contains a robust java.net package
that contains these classes.
The sample program below demonstrates the above
concepts. It represents a datagram client that connects to a particular datagram service. The
important steps that the program performs are as follows:
- It obtains a new DatagramConnection object.
- It gets a Datagram object from the DatagramConnection.
- It populates the Datagram with the properly formatted semantic
comprises the request. (As the
developer, ensure that the length of the datagram doesn't
exceed the maximum length allowed
by the protocol.)
- It receives a Datagram response from the DatagramConnection.
This call blocks
until a datagram is received or the
call times out.
- It processes the data in the
- It repeats the cycle for ongoing
The program doesn't
actually implement Step 3. Doing so would require constructing a properly formatted
message as expected by the service to which the client is connecting. Also, the
"processing" of Step 5 simply involves printing the server's response
to standard output. In a real
application, the client would use the datagram information in some way for local processing.
/* Datagrams are sent and received
by a datagram connection. This
program parses the payload of a received
datagram and displays it on screen. */
This class implements a datagram client
that connects to
a Network Time Protocol (NTP) server on
the NTP standard
The client is designed to be controlled
by a separate
thread, hence it implements Runnable.
can do communications asynchronously
from its UI management.
Note that this file represents only a
skeleton of a
complete client. The full semantics of
the NTP service
messages are not shown here. The
purpose is simply to
demonstrate the structure of a client
public class DatagramTest extends
implements CommandListener, Runnable
private static final int BUF_SIZE =
private static Command exit = new
Command("Exit", Command.EXIT, 1);
private static DatagramTest instance;
private Display display;
private TextBox dgramText;
// A datagram connection.
private DatagramConnection conn;
// A datagram which holds sent and
private Datagram dgram;
// The address of the Network Time
Protocol (NTP) daemon
// process on a particular server. NTP
uses the UDP
private String address =
instance = this;
Constructor. Note no validity checks
are made on the
parameter. If it is malformed, an
exception will be
thrown when the connection is
@param service the URI of the datagram
which to connect.
public DatagramTest(String service)
address = service;
Returns the single instance of this
this method before constructing an
object will return
a null pointer.
@return an instance of this class.
public static DatagramTest getInstance()
public void startApp()
display = Display.getDisplay(this);
dgramText = new TextBox("Datagram
Runs the datagram client. Opens a
connection to the
datagram service. Populates a datagram
sends it. Receives the response
writes the bytes to standard output for
purposes. Catches any connection
public void run()
// Open a client connection.
conn = (DatagramConnection)Connector.open(address);
maxLength = conn.getMaximumLength();
dgram = conn.newDatagram(maxLength);
// Ensure that the read/write pointer
is at the
// beginning of the buffer, so data
// any unitialized buffer memory.
// Populate the datagram before sending
// message that the datagram service
// Construct the request in the
// Send the datagram just populated.
// Receive a datagram; its contents are
// the referenced datagram object.
// Use this byte array to transfer the
// the server's response to a more
// object like a String. You can then
// datagram for another send or receive
byte data = dgram.getData();
// Extract the response string.
String str = new String(data);
// Do some processing with the
// just print it out for demonstration.
// Reset the read/write pointer for the
// object. The next time data is
written into the
// datagram buffer, it will overwrite
// from the previous send or receive
// This ensures that previous and next
// not mixed in the same buffer, and
// garbled messages.
// Continue processing, maybe sending
// receiving more messages from the
catch (IOException ioe)
public void pauseApp()
public void destroyApp(boolean destroy)
catch (IOException ioe)
public void display()
public void commandAction(Command c,
if (c == exit)
Notice that any Datagram objects by default contain the same address
as the DatagramConnection object
that constructs them. You can change the address of a datagram using the methods in the
The application must supply a Datagram object to send or receive a datagram. To
send a datagram, the application populates
the datagram object with data that constitutes the message to be sent to the server. When an
application receives a datagram, its connection object populates the datagram object with the data it
receives from the sender.
You can use the same datagram
object to send and receive multiple messages. To do so, you must ensure that you don't mix data from
different messages. Before reusing a datagram object to send or receive a new message, use the
Datagram.reset() method to reset the read/write buffer pointer.
A Datagram object has a buffer that stores the bytes
that comprise the message being sent or received. If you reuse a Datagram object, the bytes that were placed in the
buffer from the previous send or receive operation
are still there. Calling reset() sets
the read/write offset pointer to point to the beginning
of this buffer and sets the length to zero. Thus, you're effectively overwriting any previous data,
ensuring that you are not mixing bytes from two separate messages.