Warenkorb
0 Artikel | US$ 0,00
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.
© Diplomica GmbH
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
1
Overview
1
1.1 Architecture
1
Constituent Components
2
Protocol Data Unit
4
1.2
Layers
and
Protocols
5
Data Link Layer
5
Network
Layer
5
Transport
Layer
8
1.3 Organizations and Standards
8
Internet-Related
Organizations
8
Internet
Standards
9
Chapter 2
Sockets in Berkeley Unix
11
Overview
11
2.1 Architecture
11
Network Address Data Structure
11
Network Address Byte Order and Conversion
12
Host
Information
14
Socket
Operations
14
Additional Socket Information
18
2.2 Connection-Orient Model of Communication
18
Network
Logic
10
Concurrent Application Framework
20
Distribution of Incoming TCP Segments
in Concurrent Applications
21
2.3 Connectionless Model of Communication
21
Network
Logic
22
Concurrent Application Framework
23
Distribution of Incoming UDP Datagrams
in Concurrent Applications
24
Contents
Chapter 3
Sockets in Java 2
25
Overview
25
3.1 Architecture
25
Host Information
26
Identifying and Accessing Resources on the Internet
27
Connection-Oriented Socket Operations
29
Connectionless Socket Operations
31
3.2 Connection-Orient Model of Communication
33
Network
Logic
33
Concurrent Application Framework
33
Distribution of Incoming TCP Segments
in Concurrent Applications
35
3.3 Connectionless Model of Communication
35
Network
Logic
36
Concurrent Application Framework
36
Distribution of Incoming UDP Datagrams
in Concurrent Applications
38
Chapter 4
Java Remote Method Invocation - RMI
39
Overview
39
4.1 Distributed Object Model in Java RMI
39
Design Concepts: Remote Interface, Remote Object
and Remote Method Invocation
40
Remote Objects and Non-Remote Objects
40
4.2 Architecture
41
Overview of Interfaces, Classes and Packages
41
Communication with Remote Objects
43
Dynamic Class Downloading in Java RMI
45
4.3 Security Considerations in Java RMI
45
Security
Manager
45
Security Policy File
46
4.4
Application
Development Process in Java RMI
47
Object Server and Client Application
47
Security Policy Files and Runtime Options
49
Contents
Chapter 5
Common Object Request Broker Architecture
50
Overview
50
5.1 Distributed Object Model in CORBA
50
Design
Concepts
51
Object Management Group
52
5.2 Interface Definition Language
52
OMG Interface Definition Language
52
IDL to Java Language Mapping
52
5.3 Interoperable Naming Service
53
Overview
53
Design
Objectives
54
Common Object Services Naming Service
54
5.4 Portable Object Adapter
55
Architecture 55
Overview and Design Objectives
55
5.5 Application Development Process in CORBA
56
Server Model and Client Model
56
Naming Service
57
Interface Definition File
57
Object Server and Client Application
57
Chapter 6
Comparative Study of Distributed Architectures
61
Overview
61
6.1 Sockets in Java 2 and Berkeley UNIX
61
Two-Tier Model of Communication
61
Socket
Architectures
63
Available Communication Domains
64
Transport Layer Protocols
65
Scalability of Application Development
66
Portability and Interoperability
68
Areas of Application
69
Application
Development Tools and Libraries
70
Educational
Effort
70
Contents
Chapter 6
Continued
6.2 Java RMI and CORBA
70
Distributed Object Model in Java RMI
70
Distributed Object Model in CORBA
72
Expressiveness of OMG IDL in Relation to Java 2
73
Scalability of Application Development
79
Portability and Interoperability
79
Areas of Application
80
Application
Development
Tools, Libraries and Policy Files 81
Educational
Effort
81
6.3 Conclusions and Comparative Tables
82
Sockets in Java 2 and Berkeley UNIX
82
Java RMI and CORBA
83
Expressiveness of OMG IDL in Relation to Java 2
84
Chapter 7
Summary
85
Annotated Bibliography 86
1
1
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
IP Router
IP Router
Network
Network
Fig. 1. TCP/IP-based networks connected through a series of routers.
TCP/IP
Host
TCP/IP
TCP/IP
Host
Host
2
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
IP
Ethernet CSMA/CD
Fig. 3. Communication between hosts sharing a common subnetwork.
IP
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
Host Application
3
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
Data Link layer
Data Link layer
Subnetwork B
Subnetwork C
Fig. 5. Communication between hosts attached to two separate subnetworks.
Protocol B
IP
IP
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
Data Link layer
Host Application
Host Application
4
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
IP
Ethernet CSMA/CD
Application
data
Application layer
protocol header
Application
data
Application
data
Application layer
protocol header
TCP/UDP
header
IP
header
IP
packet
Application
data
Application layer
protocol header
TCP/UDP
header
TCP/UDP
segment/datagram
Application
data
Application layer
protocol header
TCP/UDP
header
IP
header
Ethernet
trailer
Ethernet
header
Ethernet
frame
Fig. 6. TCP/IP suite protocols and their related data units
5
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
IP
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-
6
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.
0
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
7
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
00000000
Fig. 10. Class A IP address and optional 14-bit subnetwork below.
00000000
11111111
00000000
11111100
11111111
Class A
Class A
8
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.
9
· 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
10
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.
11
2
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
Host
TCP/IP-based communication technology
Endpoint of
Communication
Berkeley Unix
Socket API
Endpoint of
Communication
Berkeley Unix
Socket API
Ende der Leseprobe aus 102 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2005, Distributed Object-Oriented Architectures: Sockets, Java RMI and CORBA, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/228753
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare