Distributed Object-Oriented Architectures: Sockets, Java RMI and CORBA

Stepisnik, Josef

Distributed Object-Oriented Architectures: Sockets, Java RMI and CORBA

Informatik - Internet, neue Technologien

Zusammenfassung

Inhaltsangabe:Abstract:
Distributed computing is playing an increasingly important role in many areas of industry, the sciences, in business processes and in the development of new and emerging technologies. It facilitates inter-process communication across heterogeneous networks, hardware platforms and operating systems.
We compare four distributed and object-oriented architectures: Sockets in Java 2, Sockets in Berkeley Unix, Remote Method Invocation in Java - RMI - and the Common Object Request Broker Architecture - CORBA - of the Object Management Group consortium. We provide a survey of each of the distributed architectures including its constituting components. To present the architectures in a practical context, we amend each survey with a corresponding application framework.
We conclude with a comparative study of the Socket APIs in Java 2 and in Berkeley UNIX and the distributed object models of Java RMI and CORBA. Although the distributed object model as defined by CORBA represents an adopted industry standard, Java RMI has features unattainable by CORBA.
The first part of the discussion offers a comprehensive overview of the Socket architecture in Java 2 and Berkeley UNIX and the distributed object model of Java Remote Method Invocation and the Common Object Request Broker Architecture.
The second part concludes the discussion with a comparative study of selected features with emphasis on the Common Object Request Broker Architecture and Java Remote Method Invocation.
Chapter 1 - The TCP/IP Protocol Suite: We provide an introductory overview of the TCP/IP protocol suite and its architecture including layers and protocols. The TCP/IP architecture is based on three concepts: processes, layers and protocols. There is no official protocol model as compared to the OSI proposal. We can however devise a logical structure of the TCP/IP protocol suit based on the associated protocols and their relationships. The chapter concludes with a brief discussion of Internet-related organizations and standards.
Chapter 2 - Sockets in Berkeley Unix: We present the Berkeley UNIX socket architecture in relation to the Internet communication domain and illustrate connection-oriented and connectionless models of communication. The socket architecture forms the basis for the development of distributed applications. A socket represents an endpoint of communication for connectionless or connection-oriented protocols. A socket address data structure […]

Leseprobe

Inhaltsverzeichnis

Josef Stepisnik

Distributed Object-Oriented Architectures

Sockets, Java RMI and CORBA

ISBN: 978-3-8324-9333-2

Druck Diplomica® GmbH, Hamburg, 2007

Zugl. Technische Universität Wien, Wien, Österreich, Diplomarbeit, 2005

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

http://www.diplom.de, Hamburg 2007

Printed in Germany

To My Parents

Abstract

Distributed computing is playing an increasingly important role in many areas of industry, the

sciences, in business processes and in the development of new and emerging technologies. It

facilitates inter-process communication across heterogeneous networks, hardware platforms

and operating systems.

We compare four distributed and object-oriented architectures: Sockets in Java 2, Sockets in

Berkeley Unix, Remote Method Invocation in Java - RMI - and the Common Object Request

Broker Architecture - CORBA - of the Object Management Group consortium.

We provide a survey of each of the distributed architectures including its constituting

components. To present the architectures in a practical context, we amend each survey with a

corresponding application framework.

We conclude with a comparative study of the Socket APIs in Java 2 and in Berkeley UNIX

and the distributed object models of Java RMI and CORBA.

Although, the distributed object model as defined by CORBA represents an adopted industry

standard, Java RMI has features unattainable by CORBA.

Kurzfassung

Die Anwendung verteilter Systeme erhält zunehmende Bedeutung in vielen industriellen

Bereichen, in den Wissenschaften, in Geschäftsprozessen und in der Entwicklung neuer und

entstehender Technologien. Sie ernöglichen eine Interprozeßkommunikation über heterogene

Netzwerke, Hardware-Plattformen und Betriebssysteme.

Wir vergleichen vier verteilte und objektorientierte Architekturen: Sockets in Java 2 und in

Berkely UNIX, Remote Method Invokation in Java RMI und die Common Object

Request Broker Architecture CORBA des Object Management Group Konsortiums.

Wir erstellen einen detaillierten Überblick zu den einzelnen verteilten Architekturen

einschließlich ihrer konstituierenden Komponenten. Um die Architekturen in einem

praktischen Kontext darzustellen, erweitern wir jede unserer Betrachtungen um eine

dazugehörige illustrierende Applikation.

Wir beenden unsere Betrachtungen mit einer vergleichenden Studie über die Socket APIs in

Java 2 und Berkeley UNIX und die verteilten Objektmodelle von Java RMI und CORBA.

Obwohl das verteilte Objektmodell von CORBA einen anerkannten Industriestandard

representiert bietet Java RMI dennoch Eigenschaften welche für CORBA unerreichbar sind.

Introduction

Distributed computing is playing an increasingly important role in many areas of industry, the

sciences and in the development of new and emerging technologies. This document intends to

offer a detailed discussion of selected distributed object-oriented architectures that have

become established in industry.

The first part of the discussion offers a comprehensive overview of the Socket architecture

in Java 2 and Berkeley UNIX and the distributed object model of Java Remote Method

Invocation and the Common Object Request Broker Architecture.

The second part concludes the discussion with a comparative study of selected features

with emphasis on the Common Object Request Broker Architecture and Java Remote Method

Invocation.

Part One

Chapter 1

The TCP/IP Protocol Suite

We provide an introductory overview of the TCP/IP protocol suite and its architecture

including layers and protocols. The TCP/IP architecture is based on three concepts: processes,

layers and protocols. There is no official protocol model as compared to the OSI proposal.

We can however devise a logical structure of the TCP/IP protocol suit based on the associated

protocols and their relationships. The chapter concludes with a brief discussion of Internet-

related organizations and standards.

Chapter 2

Sockets in Berkeley Unix

We present the Berkeley UNIX socket architecture in relation to the Internet communication

domain and illustrate connection-oriented and a connectionless models of communication.

The socket architecture forms the basis for the development of distributed applications. A

socket represents an endpoint of communication for connectionless or connection-oriented

protocols. A socket address data structure constitutes a platform for the communication of

host address information between the operating system and the network application. A

connection-oriented model of communication uses the Transmission Control Protocol.

Transmission of data is in the form of segments. A connectionless model of communication is

based on the User Datagram Protocol and the transmission of data is in the form of

datagrams.

Chapter 3

Sockets in Java 2

We describe the Java 2 socket architecture, outline selected socket operations, introduce

related packages and classes and conclude with a framework for a connection-oriented and

connectionless model of communication. The Java 2 socket architecture was developed by

Sun Microsystems, Inc. and is proprietary and language constrained. It is made available in

the form of a class library referred to as package java.net and is functionally similar to the

sockets API introduced by Berkeley UNIX. The class library provides for hostname

resolution and reverse host name resolution. In addition, classes are available for the

transmission of data across connection-oriented or connection-less channels of

communication.

Chapter 4

Remote Method Invocation in Java

We present a distributed object model in Java RMI, provide an overview of related interfaces,

classes and packages and discuss security related issues. We conclude with the development

of a framework for a distributed object application. Remote Method Invocation was

developed by Sun Microsystems, Inc. It is a proprietary and language-constrained

technology. Invocations of remote and local methods are syntactically identical. They differ

only in the types of parameters and return values. Remote objects can be uniquely identified

within a Java distributed object model based on their remote object references. Java RMI uses

an enhanced model of security in its recent releases. Every RMI client application and object

server requires the presents of an RMI security manager and the specification of a security

policy file.

Chapter 5

Common Object Request Broker Architecture

We introduce a distributed object model for the Common Object Request Broker

Architecture and outline design concepts including the Interface Definition Language and the

Interoperable Naming Service. We conclude with the development of a framework for a

distributed object application. CORBA was developed in the form of a set of specifications

by members of the Object Management Group consortium and is vendor-independent. It has

developed into an industry standard and provides transparency and interoperability across

different hardware platforms and operating systems.

Part Two

Chapter 6

Comparative Study of Distributed Architectures

We present a comparative study of socket architectures and distributed object models

introduced in part one of this document. It provides an overview of the technical capabilities,

similarities and areas of application in industry of each of these architectures.

Chapter 7

Summary

We conclude the document with a brief summary and detailed annotated bibliographic

references of papers, technical articles, standards, and specifications.

Sources of Information and References

This document is based on specifications, guidelines, Internet drafts and Internet standards

issued by the Object Management Group consortium, Sun Microsystems, Inc. and the

Internet Engineering Task Force IETF.

In particular, the material for the TCP/IP protocol suit was obtained from IETF. Its

responsibility includes the dissemination of Internet Drafts, referred to as Ready for

Comments RFCs. The chapters on the Java 2 Socket API and the Java Remote Method

Invocation architecture are based on specifications provided by Sun Microsystems, Inc. The

Sockets API in Berkeley UNIX is outlined in the corresponding documentation of Release

4.2. The Common Object Request Broker Architecture is documented in great detail in the

form of specifications and introductory material issued by the Object Management Group

consortium.

Contents

Abstract

Kurzfassung

Introduction

Chapter 1

The TCP/IP Protocol Suite

Overview

1.1 Architecture

Constituent Components

Protocol Data Unit

1.2

Layers

and

Protocols

Data Link Layer

Network

Layer

Transport

Layer

1.3 Organizations and Standards

Internet-Related

Organizations

Internet

Standards

Chapter 2

Sockets in Berkeley Unix

Overview

2.1 Architecture

Network Address Data Structure

Network Address Byte Order and Conversion

Host

Information

Socket

Operations

Additional Socket Information

2.2 Connection-Orient Model of Communication

Network

Logic

Concurrent Application Framework

Distribution of Incoming TCP Segments

in Concurrent Applications

2.3 Connectionless Model of Communication

Network

Logic

Concurrent Application Framework

Distribution of Incoming UDP Datagrams

in Concurrent Applications

Contents

Chapter 3

Sockets in Java 2

Overview

3.1 Architecture

Host Information

Identifying and Accessing Resources on the Internet

Connection-Oriented Socket Operations

Connectionless Socket Operations

3.2 Connection-Orient Model of Communication

Network

Logic

Concurrent Application Framework

Distribution of Incoming TCP Segments

in Concurrent Applications

3.3 Connectionless Model of Communication

Network

Logic

Concurrent Application Framework

Distribution of Incoming UDP Datagrams

in Concurrent Applications

Chapter 4

Java Remote Method Invocation - RMI

Overview

4.1 Distributed Object Model in Java RMI

Design Concepts: Remote Interface, Remote Object

and Remote Method Invocation

Remote Objects and Non-Remote Objects

4.2 Architecture

Overview of Interfaces, Classes and Packages

Communication with Remote Objects

Dynamic Class Downloading in Java RMI

4.3 Security Considerations in Java RMI

Security

Manager

Security Policy File

4.4

Application

Development Process in Java RMI

Object Server and Client Application

Security Policy Files and Runtime Options

Contents

Chapter 5

Common Object Request Broker Architecture

Overview

5.1 Distributed Object Model in CORBA

Design

Concepts

Object Management Group

5.2 Interface Definition Language

OMG Interface Definition Language

IDL to Java Language Mapping

5.3 Interoperable Naming Service

Overview

Design

Objectives

Common Object Services Naming Service

5.4 Portable Object Adapter

Architecture 55

Overview and Design Objectives

5.5 Application Development Process in CORBA

Server Model and Client Model

Naming Service

Interface Definition File

Object Server and Client Application

Chapter 6

Comparative Study of Distributed Architectures

Overview

6.1 Sockets in Java 2 and Berkeley UNIX

Two-Tier Model of Communication

Socket

Architectures

Available Communication Domains

Transport Layer Protocols

Scalability of Application Development

Portability and Interoperability

Areas of Application

Application

Development Tools and Libraries

Educational

Effort

Contents

Chapter 6

Continued

6.2 Java RMI and CORBA

Distributed Object Model in Java RMI

Distributed Object Model in CORBA

Expressiveness of OMG IDL in Relation to Java 2

Scalability of Application Development

Portability and Interoperability

Areas of Application

Application

Development

Tools, Libraries and Policy Files 81

Educational

Effort

6.3 Conclusions and Comparative Tables

Sockets in Java 2 and Berkeley UNIX

Java RMI and CORBA

Expressiveness of OMG IDL in Relation to Java 2

Chapter 7

Summary

Annotated Bibliography 86

The TCP/IP Protocol Suite

Government-funded research activities initiated by the Advanced Research Projects Agency

ARPA - in the late 1960`s and conducted in the area of packet-switched networks have

concluded in the early 1980`s with a new vendor-independent family of layers and protocols

commonly referred to as the TCP/IP protocol suite. The corresponding standards have been

issued by the Internet Architecture Board [IAB].

The TCP/IP protocol suite defines a set of network standards for interconnecting

networks of any size without any geographical restrictions and independent from the

underlying transmission technology. It accomplishes communication activities across

heterogeneous packet-switched networks.

The Internet Protocol version 4 or IPv4 standard was adopted in September 1981. It uses 32-

bit addresses and provides packet switching and routing across networks. IPv4 is being

replaced by IPv6, which is based on 128-bit addresses.

Throughout this document, the term IP will refer exclusively to IPv4. Furthermore, we

consider the Ethernet technology the prevailing local area network standard. It is therefore

used in all our illustrations unless otherwise indicated.

We intend to provide an introductory overview of the TCP/IP protocol suite. We describe

the architecture and its constituent parts, review the layers and protocols and conclude with

Internet-related organizations and standards.

1.1 Architecture

The architecture of the TCP/IP protocol suite is based on three underlying concepts:

processes, hosts and networks. Processes execute on hosts and communicate across

interconnected and packet-switched networks.

We present the architecture and its constituent components, outline the main features and

provide a description of the protocol data units [Rfc768], [Rfc791], [Rfc793].

IP Router

Network

Fig. 1. TCP/IP-based networks connected through a series of routers.

TCP/IP

Host

TCP/IP

Host

Constituent Components

There is no official TCP/IP protocol model as compared to the Open System Integrated - OSI

proposal. We can however, based on the protocols that have been developed for the TCP/IP

suite, devise the following logical structure of layers and its associated protocols as presented

below.

As indicated earlier, hosts, processes and networks represent important components of any

TCP/IP suite architecture. Therefore, we need appropriate addressing schemes to identify

processes on a host and hosts in a network.

A host may have several physical network interfaces and every interface on the Internet

must have a globally unique Internet address or IP address. Each process executing within a

host must have a unique address within that host to support transport layer or host-to-host

communication. These addresses are referred to as ports.

IP addresses identify hosts on network. They are 32 bits wide and consist of a network

address and a host address within that network. They are written in dotted decimal notation as

four decimals representing the four bytes separated by dots.

Port addresses identify processes on a host. They are 16 bit wide and represented in

decimal notation. Each server knows his port number. The range between 1 and 1023 is

referred to as well-known port numbers. A client process can allocate any port number

available on his host. A server needs to be aware of the port number to which he provides his

services. An ftp server for instance uses port 21 to communicate with client processes and

port 20 for the transmission of data. The relationship between hosts, protocol layers and their

respective protocols based on a common subnetwork is illustrated below.

Fig. 2. TCP/IP suite: Layers and representative protocols.

Application layer

Transport layer

Network layer

Data Link layer

UDP, TCP

Http, Ftp

Ethernet CSMA/CD

Fig. 3. Communication between hosts sharing a common subnetwork.

Network

Ethernet CSMA/CD, Token Ring

TCP, UDP

Application layer protocol Http, Ftp

Application layer

Transport layer

Network layer

Data Link layer

Application layer

Transport layer

Network layer

Data Link layer

Host Application

Each layer provides at least one protocol to support communication between peers through

logical connections. Physical connections are established through network interface cards

attached to a transmission medium.

To verify that two communicating hosts share the same subnetwork we extract the

network address from both IP addresses. A match indicates a common subnetwork. The IP

packet includes source and destination IP addresses. The Ethernet frame carries source and

destination Ethernet addresses. The network model as presented above is based on the

assumption, that all communicating hosts share a common subnetwork. To support

internetworking we need to extend our network architecture and connect separate

subnetworks through a series of IP Routers.

Application

and

transport layer protocols are referred to as point-to-point or end-to-end

protocols. On the contrary, services at network or data link level are concerned with machine-

to-machine, or host-to-host related issues. The TCP/IP protocol suite uses two addressing

schemes: All protocols from the network layer upwards are based on IP addresses. Frames

generated by the data link layer include physical addresses for instance Ethernet addresses.

Subnetworks and IP Routers represent the constituent parts of any communication

infrastructure. IP Routers are used to interconnect subnetworks and to implement subnet

addressing in large corporate networks. Their key responsibility is the forwarding of IP

packets based on routing tables.

Application gateways or gateways connect hosts based on entirely different protocol

suites. Therefore, Gateways require the full installation of both protocol suites. The

distinction between end systems and intermediate system leads to an extended network

architecture as outlined in Figure 4 and 5 below.

Each network interface card installed requires its own Data Link layer to provide the

supported protocols. As a consequence, TCP/IP suites based on different Data Link layer

protocols, Ethernet and Token ring for instance, may be connected through IP-Routers.

Fig. 4. IP Router connecting three separate subnetworks.

Subnetwork A

Network layer

Data Link layer

Subnetwork B

Subnetwork C

Fig. 5. Communication between hosts attached to two separate subnetworks.

Protocol B

Subnetwork B

Protocol A

Subnetwork A

TCP, UDP

Application layer protocol Http, Ftp

Application layer

Transport layer

Application layer

Transport layer

Network layer

Data Link layer

Network layer

Data Link layer

Network layer

Data Link layer

Host Application

The lower three layers are concerned with the reliable and efficient transmission of data

between processes executing on different hosts across interconnected networks. The

application layer builds on the functionality provided by the lower layers and places emphasis

on the application specific details.

We would like to emphasize the difference between end-to-end and host-to-host

communication. Protocols A and B in Figure 5 are arbitrary data link layer protocols as

determined through the attached network interface cards.

The frames delivered by protocol A are different from the frames transmitted by protocol

B. The forwarding process is accomplished by IP routers. Source and destination IP addresses

correspond to the communicating hosts. However, the destination Ethernet address refers to

the IP router network interface card. As indicated earlier, destination hosts outside the current

subnetwork are identified based on the network address component.

Furthermore, the same concept applies to IP packets. A time-to-live counter is modified

every time the IP packet passes through an IP router. It is used to prevent indefinite routing of

IP packets and to identify cycles in routing tables.

Protocol Data Unit

The amount of data exchanged between peers through their logical connection is referred to

as protocol data unit PDU. It includes the protocol header and application related data. We

illustrate the concept through a protocol stack as needed by a TCP-based application layer

protocol. The name of a protocol data unit including its components depends upon where it is

located within the TCP/IP protocol suite.

Application layer protocol

TCP or UDP

Ethernet CSMA/CD

Application

data

Application layer

protocol header

Application

data

Application

data

Application layer

protocol header

TCP/UDP

header

packet

Application

data

Application layer

protocol header

TCP/UDP

header

TCP/UDP

segment/datagram

Application

data

Application layer

protocol header

TCP/UDP

header

Ethernet

trailer

Ethernet

header

Ethernet

frame

Fig. 6. TCP/IP suite protocols and their related data units

The application data generated by the user process is successively appended with protocol

headers as it is forwarded down the TCP/IP suite. Contents and structure of the data link layer

frame my vary depending on the technology supported by the network interface card.

On the destination host the data link layer frame is forwarded up the protocol stack to the

receiving process as each layer detaches its respective protocol header. The concept and its

associated terminology are presented in detail below.

The summary below illustrates the correspondence between protocol layer, protocol, data

unit and communicating parties.

Layer Protocol

Data

Unit

Communication

Transport

TCP

Segment

End-to-End

Transport UDP

Datagram End-to-End

Network

Packet

Host-to-Host

Data Link

Ethernet CSMA/CD

Frame

Host-to-Host

1.2 Layers and Protocols

The transport, network and data link layers are concerned with the reliable and efficient

transmission of data between processes executing on different hosts across interconnected

networks.

We describe the protocol layers and selected protocols representative for their respective

layers, outline main features and indicate limitations [Rfc768], [Rfc791], [Rfc793].

Data Link Layer

The key activity of the data link layer is to provide direct access to the underlying physical

network connection and to support the transmission of Ethernet frames. Ethernet frames

include, in addition to the data field, source and destination addresses. An Ethernet address is

6 bytes wide and written in hexadecimal form. Individual bytes are separated with either a

colon or a dash. Every network interface has its own Ethernet address. They are commonly

referred to as hardware or physical addresses.

Ethernet technology is based on the Carrier Sense, Multiple Access with Collision

Detection - CSMA/CD protocol, which forms part of the Ethernet device driver and

operates at 10 MBits/sec. All network interfaces on a shared communication medium can

listen simultaneously but may transmit mutually exclusive only. Any concurrent

transmissions of Ethernet frames are detected and lead to randomly established delays of both

network interfaces.

To support local development of TCP/IP applications, any data link layer provides loop-

back support. That allows processes on the same host to communicate over a shared TCP/IP

stack. Any IP packet received by the loop-back interface is immediately returned to the

network layer and subsequently to the application layer. A class A network IP address

127.0.0.1 is allocated for that purpose. Alternatively, the domain name localhost may be

used. However, a TCP/IP protocol suite installation must be present.

Network Layer

The data link layer's prime responsibility is routing, the forwarding of IP packets based on

the destination network address from one subnetwork to another and hence the term packet-

switched system. Internet Protocol IP packets include source and destination Internet

addresses. The concept of a port number does not exist at network layer level. No data

validation of IP packets is performed. IP addresses were designed with routing operations in

mind. They identify devices such as hosts, routers and printers on a network. They are 32 bits

wide and consist of a network address and a host address within that network. IP addresses

are written in dotted decimal notation as four decimals representing the four bytes separated

by dots. There are three types of networks, A, B and C corresponding to three classes of IP

addresses as outlined below.

The class of an IP address is determined by its high-order bits. The correspondence between

classes of networks and ranges of IP addresses is indicated below.

Class A

0.0.0.0 to 127.255.255.255

Class B

128.0.0.0 to 191.255.255.255

Class C

192.0.0.0 to 223.255.255.255

The network address component is assigned by the Internet Network Information Center

InterNIC on a global basis. Allocation of host addresses falls under the responsibility of the

local network administration.

Multicasting

IP multicasting [Rfc1112] is based on UDP and provides for a transmission of IP packets to a

group of hosts sharing a common IP destination address. Multicasting reduces the

communication overhead imposed on the network and the communicating hosts in return for

reduced reliability. Efficient delivery of mail to several recipients represents one area of

application. Without multicasting, each delivery would require a separate TCP connection.

Each multicast group address corresponds to a class D IP address and begins with 1110. The

remaining 28 bits may be allocated arbitrarily. The format of a multicast group addresses

including the range of multicast group addresses appears below.

A single multicast datagram is delivered to all host members sharing a common multicast

group.

Class A

1 0

1 1 0

Class B

Class C

Fig. 7. Three classes of IP addresses. Each block represents one network

or host address byte. The network address bytes are dimmed.

1 1 1 0

Fig. 8. Multicast group address: format and range. Each block represents one byte.

Class D

Range of multicast group addresses: 224.0.0.0 to 239.255.255.255

The group of hosts associated with a particular multicast group address is not restricted to

subnetworks. Membership is dynamic and each host can participate in several multicast

groups. Multicast routers require an additional protocol to identify any host on a subnetwork

belonging to a specific multicast group. This protocol is referred to as the Internet Group

Management Protocol IGMP.

The Internet Assigned Number Authority IANA assigns well-known multicast group

addresses. Details are available from the Assigned Numbers RFC [Rfc1700]. For instance,

224.0.0.1 and 224.0.0.2 refer to All system on the current subnetwork and All routers on the

current subnetwork respectively.

Subnetwork Addressing

Subnetworks [Rfc950] are used to structure large corporate networks. The decision is entirely

the responsibility of the network administration. Subnetworks are transparent to any router

outside the respective network. The selection of subnetworks can be based on functional or

regional considerations.

As indicated earlier, the IP network address component is provided by InterNIC. Should

an organization decide to implement subnetworking in its corporate network, the host address

component is further divided into a subnet address and a reduced host address part.

Each subnet address represents an individual subnetwork and is attached to a separate

router. It is recommended to obey 8-bit boundaries as the subnetwork address can than be

derived from the IP address in dotted notation. As all routing table entries refer to network

addresses, subnet addressing reduces their size.

The application of subnetworking to a class A IP address is illustrated below. The

subnetwork address is 14 bits long and consequently reduces the host address from 24 bits to

10 bits.

Subnetwork Mask

A subnetwork or subnet mask determines the number of bits allocated to the subnet address

whereas the network class establishes the size of the network address. A subnet mask is a 31-

bit quantity that uses 1 to indicate network or subnetwork components and 0 to refer to the

host address. They are commonly written in dotted decimal notation. The subnet masks

corresponding to the IP addresses illustrated earlier are indicated below.

Fig. 9. Subnetworking applied to a class A IP address.

Network address - 8 bits

Host address - 24 bits

Class A

Network address - 8 bits

Host address - 10 bits

Subnetwork address - 14 bits

Class A

11111111

00000000

Fig. 10. Class A IP address and optional 14-bit subnetwork below.

00000000

11111111

00000000

11111100

11111111

Class A

Transport Layer

The TCP/IP protocol suite provides two essentially different transport layer protocols, TCP

and UDP, to support the transmission of application data between processes on different

machines. Both, TCP segments and UDP datagrams include source and destination port

addresses as well as checksum fields to verify the integrity of their data components.

Transmission Control Protocol TCP

TCP provides a connection-oriented or session-oriented transmission of application data

between processes executing on separate machines. TCP connections are uniquely

determined based on four components: local IP and port address and remote IP and port

address. All four components remain invariant for the lifetime of a connection.

Communication is performed at byte level. Record boundaries need to be inserted at

application level. A TCP segment includes source and destination port number. Transmission

of data is in full duplex, complete and in correct sequence. Data integrity is retained to a

certain extend. Each write operation may require several read operations for the same amount

of data. Flow control allows for transmissions of data between hosts performing at different

level.

User Datagram Protocol UDP

UDP provides a connectionless or datagram-oriented transmission of application data

between processes executing on separate machines. The distribution of incoming UDP

datagrams to its corresponding endpoints of communication is entirely based on port

addresses.

Communication is performed at datagram or record level. A UDP datagram includes

source and destination Internet address and port number. Receipt of information is not

acknowledged and the initial sequence is not verified. Any error-detection capabilities need to

be provided at application level. Each read and write operation leads to exactly one datagram.

1.3 Organizations and Standards

The Internet Architecture Board IAB - provides guidance and technical assistance to all

activities pertaining to the TCP/IP protocol suite.

We briefly discuss major Internet-related organizations and introduce the standardization

process of Internet protocols. Further details may be obtained from their respective Internet

sites.

Internet-Related Organizations

The Internet Architecture Board - IAB - is a technical advisory group of the Internet

Society concerned with standards, technical, organizational, architectural and procedural

issues. Its responsibilities include guidance and supervision of research and development

activities underlying the TCP/IP protocol suite conducted by the various task forces. In

particular, IAB provides technical guidance and advice in the in the following areas:

· The architecture for the protocols and procedures used by the Internet.

· Establishment of Internet Standards. In addition, IAB serves as an appeal board for

complaints of improper execution of the standards process.

· Editorial management and publication of the Request for Comments - RFC document

series including its sub-series.

· Administration of the Internet Assigned Numbers

It decides when a protocol draft becomes a standard and provides official policies. IAB does

not provide any funding [IAB].

The Internet Society - ISOC - is a professional membership organization providing the legal

framework for the Internet Engineering Task Force and the Internet Architecture Board. Its

members include more than 6000 individuals and organizations in over 100 countries [ISOC].

The Internet Engineering Task Force - IETF - was established in 1986 and is the protocol

engineering and development group of the Internet. It represents an international community

of network designers, operators, vendors, and researchers concerned with the evolution of the

Internet and its constituent parts. The technical work of the IETF is done in meetings and

working groups organized by technical areas.

Its responsibilities include the dissemination of

Internet drafts in the form of Ready for Comments RFCs [IETF].

The Internet Research Task Force IRTF - explores future Internet-related issues and

promotes active research in areas including Internet protocols, applications, architecture and

technology through respective research groups with emphasis on teamwork and collaboration

[IRTF].

The Internet Assigned Numbers Authority IANA - is dedicated to preserving the central

coordinating functions in the form of services in the areas of Domain Name Administration,

Internet Protocol Addresses as well Protocol Numbers and their Assignment [IANA].

Internet Standards

The Request for Comments - RFCs - documents represents a forum for all aspects on

computer-communication with emphasis on networking. It was initiated in 1969 and includes

some 3000 technical contributions. All RFCs are cross-referenced to indicate documents that

were obsoleted by or obsolete the document under consideration. The RFC repository is

maintained by the IETF secretariat.

RFC documents are provided by the Internet Engineering Task Force, organizations,

companies or individuals and submitted to the RFC editor for publication in the form of

memos available to the general public.

The RFC document series includes the following sub-series: Internet Standards

Documents - STD, Best Current Practices BCP and Informational RFC Documents FYI.

Furthermore, there are two RFC sub-series on Experimental Protocols and Historic Protocols.

Internet Standards Documents

In order for a RFC document to become a standard protocol it has to undergo a series of

evaluation procedures as indicated below.

· Standard Protocol

· Draft Standard Protocol

· Proposed Standard Protocol

The Standards Protocols and their constituent RFC documents directly relating to the scope

of this document are referenced in the Annotated Bibliography and include:

· Internet Protocol STD0005, September 1981, which is based on the following

RFC documents:

RFC0791

RFC0792

RFC0919

RFC0922

RFC0950

RFC1112

· User Datagram Protocol STD0006, 28 August 1980, which is based on RFC

document

RFC0768

· Transmission Control Protocol STD0007, September 1981, which is based on

RFC document

RFC0793

Best Current Practices

The Best Current Practices RFC documents sub-series is designated to provide a source of

information on most appropriate configurations, approaches or strategies to the Internet

community.

Informational RFC Documents

The Informational RFC documents sub-series represents a resource on various Internet

related issues. It varies in its level of sophistication from introductory topics to advanced

materials. Issues discussed may range from historical accounts to commonly asked questions.

Sockets in Berkeley Unix

Sockets represent a general mechanism for inter-process communication across various

networks. Sockets were first introduced with the Berkeley Software Distribution BSD -

Release 4.2 of the UNIX system and made available in 1983. The initial socket

implementation was based on the TCP/IP protocol suite. Currently available socket

implementations provide support for various communication domains or address families: the

Unix domain to facilitate communication between processes executing on the same machine,

the Internet domain to enable communication based on the TCP/IP protocol suite and the

XNS domain which utilizes the Xerox network system protocols.

Throughout the document, we will concentrate exclusively on the TCP/IP-based Internet

address family unless otherwise indicated. Sockets are defined by the socket address data

structure and represent endpoints of communication. The socket application-programming

interface Socket API is presumed to be the most significant network API for the

development of distributed applications based on the TCP/IP protocol suite [Lef86], [Sec86].

We intend to focus on socket network programming. Implementation related issues are

documented in [Lef93]. We present the socket architecture for the Internet communication

domain and outline connection-oriented and connectionless models of communication.

2.1 Architecture

The socket architecture in Berkeley UNIX forms the basis for the development of distributed

applications. A socket is an endpoint of communication for connectionless or connection-

oriented protocols.

We discuss network address data structures and byte orders including address conversion

functions. We then conclude with host information, name-to-address translation functions and

selected socket operations. Detailed descriptions can be found in [Lef86], [Sec86],[Ste90].

Network Address Data Structures

To make the socket network interface available to a variety of socket address formats and

protocol suites, the concept of an address family was introduced. An address family or

Fig. 11. TCP/IP Application

Host

TCP/IP-based communication technology

Endpoint of

Communication

Berkeley Unix

Socket API

Endpoint of

Communication

Berkeley Unix

Socket API

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2005
ISBN (eBook): 9783832493332
DOI: 10.3239/9783832493332
Dateigröße: 768 KB
Sprache: Englisch
Institution / Hochschule: Technische Universität Wien – Informatik, Computersprachen
Erscheinungsdatum: 2006 (Februar)
Note: 1,0
Schlagworte: java sockets corba computing object client architecture rmi

Autor

Josef Stepisnik (Autor:in)

Distributed Object-Oriented Architectures: Sockets, Java RMI and CORBA

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Josef Stepisnik (Autor:in)