Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking...

Page 1 of 6

Part of the EE Times Network

Top news from EE Times:

Interview: Vint Cerf on what the Net needs now

All

Articles

Products

Course

TechPaper

Webinars

Login | Register Welcome, Guest

HOME

DESIGN

FORUMS

E-LEARNING

PRODUCTS

Thursday, June 10, 2010

Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and
networking middleware examples
Part 3 of an excerpt from the book "Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers" looks at a transport layer middleware
example using the User Datagram Protocol, as well as examples of embedded Java and networking middleware.

[Part 1 of this article begins by defining "middleware" and looking at some networking middleware driver examples. Part 2 offers pseudocode examples for PPP Link Control
Protocol states and a look at the IP networking layer protocol.]

Transport Layer Middleware Example: User Datagram Protocol (UDP)

The two most common transport layer protocols are the transmission control protocol (TCP) and the user datagram protocol (UDP). One of the
main differences between the two protocols is reliability. TCP is considered reliable because it requires acknowledgments from recipients of its
packets. If it doesn't receive them, TCP then retransmits the unacknowledged data.

UDP, on the other hand, is an unreliable transport layer protocol, because it never knows whether or not the recipient of its packets actually
receive the data. In short, this example covers UDP, a simple, unreliable, datagram-oriented protocol based upon RFC768. The UDP packet is
shown in Figure 10-15.

Figure 10-15: UDP diagram [10-3]

Transport layer protocols, such as UDP (user datagram protocol), sit on top of internet layer protocols (such as IP), and are typically responsible for establishing and dissolving
communication between two specific devices. This type of communication is referred to as point-to-point communication. Protocols at this layer allow for multiple higher-layer
applications running on the device to connect point-to-point to other devices. While some transport layer protocols can also ensure reliable point-to-point data transmission, UDP is
not one of them.

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010
Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking... Page 2 of 6

While the mechanisms for establishing communication on the server side can differ from those of the client device, both client and server mechanisms are based upon the transport
layer socket. There are several types of sockets that a transport protocol can use, such as stream, datagram, raw, and sequenced packet, to name a few. UDP uses datagram sockets, a
message oriented socket handling data one message at a time (as opposed to a continuous stream of characters supported by a stream socket used by TCP, for example).

There is a socket on each end of a point-to-point communication channel, and every application on a device wanting to establish communication to another device does so by
establishing a socket. Sockets are bound to specific ports on that device, where the port number determines the application incoming data is intended for. The two devices (client and
server) then send and receive data via their sockets.

In general, on the server side a server application is running, listening to the socket, and waiting for a client to request a connection. The client essentially communicates to the server
through its port (see Figure 10-16a).

Figure 10-16a: Client connection request

Ports are 16-bit unsigned integers, meaning each device has 65536 (0-65535) ports. Some ports are assigned to particular applications (i.e., FTP = ports 20-21, HTTP = port 80, etc.).
UDP essentially includes the destination IP address and port number in the transmitted packet, there is no handshaking to verify the data is received in the correct order, or even at all.

The server determines if the received data is for one of its own applications by extracting the IP address and port number from the received packet. After the connection is
successfully established, the client application establishes a socket for communication, and the server then establishes a new socket to listen for incoming requests from other clients
(see Figure 10-16b).

Figure 10-16b: Server connection established

The pseudocode below demonstrates a sample UDP pseudocoded algorithm for processing an incoming datagram. In this example, if the socket for the received datagram is found,
the datagram is sent up the stack (to the application layer), otherwise an error message is returned and the datagram discarded.

demuxDatagram(datagram) {

....
verifyDatagramChecksum(datagram.Cheksum);

if (datagram.Length <= 1480 && datagram.Length >= 8) {

...
if (datagram.Checksum VALID) then {

findSocket(datagram,DestinationPort);

if (socket FOUND) {

sendDatagramToApp(destinationPort, datagram.Data); //send datagram to application return;

} else {
Icmp.send(datagram, socketNotFound); //indicate to internet layer that data will not reach intended application return;
}
}
}
discardInvalidDatagram();
}

Embedded Java and Networking Middleware Example

As introduced in Chapter 2, a JVM can be implemented within a system's middleware and is made up of a class loader, execution engine, and Java API libraries (see Figure 10-17).

Figure 10-17: Internal JVM components

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010
Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking... Page 3 of 6

The type of applications in a Java-based design is dependent on the Java APIs provided by the JVM. The functionality provided by these APIs differs according to the Java
specification adhered to, such as inclusion of the Real Time Core Specification from the J Consortium, Personal Java (pJava), Embedded Java, Java 2 Micro Edition (J2ME) and The
Real Time Specification for Java from Sun Microsystems. Of these standards, pJava 1.1.8 and J2ME's Connected Device Configuration (CDC) standards are typically the standards
implemented within larger embedded devices.

PJava 1.1.8 was the predecessor of J2ME CDC, and in the long term may be replaced by CDC altogether. There is a PJava 1.2 specification from Sun, but as mentioned J2ME
standards are intended to completely phase out the pJava standards in the embedded industry (by Sun). However, because there are JVMs on the market still supporting pJava 1.1.8, it
will be used as a middleware example in this section to demonstrate what networking middleware functionality is implemented via the JVM.

The APIs provided by pJava 1.1.8 are shown in Figure 10-18. In the case of a pJava JVM implemented in the system software layer, these libraries would be included (along with the
JVM's loading and execution units) as middleware components.

java.applet
java.awt
java.awt.datatransfer
java.awt.event
java.awt.image
java.beans
java.io
java.lang
java.lang.reflect
java.math
java.net
java.rmi
java.rmi.dgc
java.rmi.registry
java.rmi.server
java.security
java.security.acl
java.security.interfaces
java.sql
java.text
java.util
java.util.zip

Figure 10-18: pJava 1.1.8 APIs [10-4]

In the pJava 1.1.8 specification, networking APIs are provided by the java.net package, shown in Figure 10-19.

Interfaces
ContentHandlerFactory
FileNameMap
SocketImplFactory
URLStreamHandlerFactory

Classes
ContentHandler
DatagramPacket
DatagramSocket
DatagramSocketImpl
HttpURLConnection
InetAddress
MulticastSocket
ServerSocket
Socket
SocketImpl
URL
URLConnection
URLEncoder
URLStreamHandler

Exceptions
BindException
ConnectException
MalformedURLException
NoRouteToHostException
ProtocolException
SocketException
UnknownHostException
UnknownServiceException

Figure 10-19: java.net package [10-4]

The JVM provides an upper-transport layer API for remote interprocess communication via the client-server model (where the client requests data, etc. from the server). The APIs
needed for client and servers are different, but the basis for establishing the network connection via java is the socket (one at the client end and one at the server end). As shown in
Figure 10-20, Java sockets use transport layer protocols of middleware networking components, such as TCP/IP discussed in the previous middleware example.

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010
Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking... Page 4 of 6

Figure 10-20: Sockets and the JVM

Of the several different types of sockets (raw, sequenced, stream, and datagram, etc.), pJava 1.1.8 JVM provides datagram sockets, in which data messages are read in their entirety at
one time, and stream sockets, where data is processed as a continuous stream of characters. JVM datagram sockets rely on the UDP transport layer protocol, while stream sockets use
the TCP transport layer protocol. As shown in Figure 10-19, pJava 1.1.8 provides support for the client and server sockets, specifically one class for datagram sockets (called
DatagramSocket, used for either client or server), and two classes for client stream sockets (Socket, and MulticastSocket).

A socket is created within a higher layer application via one of the socket constructor calls, in the DatagramSocket class for a datagram socket, in the Socket class for a stream socket,
or in the MulticastSocket class for a stream socket that will be multicast over a network (see Figure 10-21).

Socket Class Constructor

Socket()
Creates an unconnected socket, with the system-default type of SocketImpl.
Socket(InetAddress, int)
Creates a stream socket and connects it to the specified port number at the specified IP address.
Socket(InetAddress, int, boolean)
Creates a socket and connects it to the specified port number at the specified IP address. Deprecated.
Socket(InetAddress, int, InetAddress, int)
Creates a socket and connects it to the specified remote address on the specified remote port.
Socket(SocketImpl)
Creates an unconnected Socket with a user-specified SocketImpl.
Socket(String, int)
Creates a stream socket and connects it to the specified port number on the named host.
Socket(String, int, boolean)
Creates a stream socket and connects it to the specified port number on the named host. Deprecated.
Socket(String, int, InetAddress, int)
Creates a socket and connects it to the specified remote host on the specified remote port.

MulticastSocket Class Constructors

MulticastSocket()
Create a multicast socket.
MulticastSocket(int)
Create a multicast socket and bind it to a specific port.

DatagramSocket Class Constructors

DatagramSocket()
Constructs a datagram socket and binds it to any available port on the local host machine.
DatagramSocket(int)
Constructs a datagram socket and binds it to the specified port on the local host machine.
DatagramSocket(int, InetAddress)
Creates a datagram socket, bound to the specified local address.

Figure 10-21: Socket constructors in datagram, multicast, and socket classes [10-4]

As shown in the pseudocode example below of a Socket class constructor, within the pJava API, a stream socket is created, bound to a local port on the client device, and then
connected to the address of the server.

Socket(InetAddress address, boolean stream)

{
X.create(stream); //create stream socket
X..bind(localAddress, localPort); //bind stream socket to port
If problem ....
X.close();//close socket
else
X.connect(address, port); //connect to server
}

In the J2ME set of standards, there are networking APIs provided by the packages within the CDC configuration and Foundation profile, as shown in Figure 10-22. In contrast to the
pJava 1.1.8 APIs shown in Figure 10-18, J2ME CDC 1.0a APIs are a different set of libraries that would be included, along with the JVM's loading and execution units, as
middleware components.

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010
Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking... Page 5 of 6

Figure 10-22: J2ME packages [10-5]

As shown in Figure 10-22, the CDC provides support for the client sockets. Specifically, there is one class for datagram sockets (called DatagramSocket and used for either client or
server) under CDC. The Foundation Profile, that sits on top of CDC, provides three classes for stream sockets, two for client sockets (Socket and MulticastSocket) and one for server
sockets (ServerSocket).

A socket is created within a higher layer application via one of the socket constructor calls, in the DatagramSocket class for a client or server datagram socket, in the Socket class for
a client stream socket, in the MulticastSocket class for a client stream socket that will be multicast over a network, or in the ServerSocket class for a server stream socket, for instance
(see Figure 10-22). In short, along with the addition of a server (stream) socket API in J2ME, a device's middleware layer changes between pJava 1.1.8 and J2ME CDC
implementations in that the same sockets available in pJava 1.1.8 are available in J2ME's network implementation, just in two different sub standards under J2ME as shown in Figure
10-23.

Figure 10-23: Sockets and the J2ME CDC-based JVM

The J2ME connected limited device configuration (CLDC) and related profile standards are geared for smaller embedded systems by the Java community.

Figure 10-24: CLDC/MIDP stack and networking

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010
Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking... Page 6 of 6

Continuing with networking as an example, the CLDC-based Java APIs (shown in Figure 10-25) provided by a CLDC-based JVM do not provide a .net package, as do the larger
JVM implementations (see Figure 10-25).

J2ME CLDC 1.1

java.io
java.lang
java.lang.ref
java.util
javax.microedition.io

J2ME MIDP 2.0

java.lang
java.util
java.microedition.lcd.ui
java.microedition.lcd.ui.game
java.microedition.midlet
java.microedition.rms
java.microedition.io
java.microedition.pki
java.microedition.media
java.microedition.media.control

Figure 10-25: J2ME CLDC APIs [10-5]

Under the CLDC implementation, a generic connection is provided that abstracts networking, and the actual implementation is left up to the device designers. The Generic
Connection Framework (javax.microedition.io package) consists of one class and seven connection interfaces:

• Connection – closes the connection

• ContentConnection – provides meta data info
• DatagramConnection – create, send, and receive
• InputConnection – opens input connections
• OutputConnection – opens output connections
• StreamConnection – combines Input and Output
• Stream ConnectionNotifier – waits for connection

The Connection class contains one method (Connector.open) that supports the file, socket, comm, datagram and http protocols, as shown in Figure 10-26.

Http Communication :
-Connection hc = Connector.open ("http:/www.wirelessdevnet.com");

Stream-based socket communication :

-Connection sc = Connector.open ("socket://localhost:9000");

Datagram-based socket communication:

-Connection dc = Connector.open ("datagram://:9000);

Serial port communication :

-Connection cc = Connector.open ("comm:0;baudrate=9000");

Figure 10-26: Connection class used

Coming up in Part 4: Application layer software examples.

Printed with permission from Newnes, a division of Elsevier. Copyright 2005. "Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers" by
Tammy Noergaard. For more information about this title and other similar books, please visit www.elsevierdirect.com.

Related links:
Guide to Embedded Systems Architecture - Part 1: Defining middleware | Part 2: PPP state pseudocode and Internet Protocol
Making the case for commercial communication integration middleware
What's different about multiprocessor software? (Part 4)
Beyond the Internet: Building Location-Based Services for Multiplatform Device Communities

All materials on this site Copyright © 2010 EE Times Group, a Division of United Business Media LLC All rights reserved.

Privacy Statement

|

Terms of Service

|

Contact

http://www.embeddedinternetdesign.com/dhandler.jhtml;jsessionid=NLRAM4NMLSHKVQE1GHOSKHWAT... 6/10/2010