Upper Layers: Mohammed Abebe (PH.D)

CHAPTER 2
Upper Layers
Mohammed Abebe (Ph.D)

Topics
2
 Introduction to Processes, Multitasking and Threads;

 Inter-thread & inter-process communications
 Client-Server Network Programming
 Unicast, multicast, broadcast;
 Sockets;
 e-mail and file transfer; ICMP, SMTP, POP3, IMAP, FTP
protocols;
 Database access
 Elements of CORBA, J2EE, CNSM6114and .NET

– Network technologies
Programming
3
Process Concept
 An operating system executes a variety of programs.
 Textbooks uses the terms job and process almost
interchangeably.
 Process – a program in execution; process execution
must progress in sequential fashion.

 A process includes:
 program counter
 stack
 data section
CNSM6114 – Network Programming
4
The Process
 Parts of a Process
 The program code, also called text section.
 Current activity including program counter, processor registers.
 Stack containing temporary data.
 Function parameters, return addresses, local variables.

 Data section containing global variables.
 Heap containing memory dynamically allocated during run time.
 Program is passive entity, process is active

 Program becomes process when executable file is loaded into memory.
 One program can be several processes.

 Consider multiple users executing the same program.

5
Process in Memory

6
Process State
 As a process executes, it changes state
 new: The process is being created
 running: Instructions are being executed
 waiting: The process is waiting for some event
to occur
 ready: The process is waiting to be assigned to a
processor
 terminated: The process has finished execution
7
Diagram of Process State

Process Control Block (PCB)
8
 Is a data structure that contains information associated with each

process.
 The information includes:
 Process state
 Program counter
 CPU registers
 CPU scheduling information
 Memory-management information
 Accounting information
 I/O status information
9
Process Control Block (PCB)

10
Process Scheduling
 Maximize CPU use, quickly switch processes onto CPU for time sharing.
 Process scheduler selects among available processes for next execution
on CPU.
 Maintains scheduling queues of processes
 Job queue – set of all processes in the system.
 Ready queue – set of all processes residing in main memory, ready and
waiting to execute.
 Device queues – set of processes waiting for an I/O device
 Processes migrate among the various queues.

11
Different Approaches to Processes
 Differences between different OS’s support of processes
include
 How processes are named
 Whether threads are provided
 How processes are represented
 How process resources are protected
 What mechanisms are used for inter-process communication and
synchronization
 How processes are related to each other
12
Threads
 A thread is a basic unit of CPU utilization;
 It comprises a thread ID, a program counter, a register set, and a stack.
 A dispatchable unit of work.
 It shares with other threads belonging to the same process its
code section, data section, and other operating-system resources,

such as open files and signals.
 A traditional (or heavy weight) process has a single thread of
control. If a process has multiple threads of control, it can

perform more than one task at a time.
13
Thread Execution States
 A simplified view of thread states is Ready, Running, and Blocked,
where
 a thread is either ready and waiting to be scheduled, is running on the
processor, or is blocked.
Spawn
Thread States
14
One or More Threads in Process
 Each thread has
 An execution state (running, ready, etc.)
 Saved thread context when not running
 An execution stack
 Some per-thread static storage for local variables
 Access to the memory and resources of its process (all threads of a process
share this)
 One way to view a thread is as an independent program counter
operating within a process.
15
Benefits of Threads
 Takes less time to create a new thread than a
process
 Less time to terminate a thread than a process
 Switching between two threads takes less time
than switching processes

 Threads can communicate with each other without
invoking the kernel.

Single Thread Approaches
16
 MS-DOS supports a single user process and a single

thread.
 Some UNIX, support multiple user processes but only
support one thread per process

Multithreading
17
 The ability of an OS to support multiple, concurrent paths of execution

within a single process.
 Multiple processes and threads are found in Windows, Solaris, and
many modern versions of UNIX

Threads vs. processes
18

19
Example: Remote Procedure Call
 Consider:
 A program that performs two remote procedure calls (RPCs) to
two different hosts to obtain a combined result.
 An RPC is a technique by which two programs, which may execute on

different machines, interact using procedure call/return syntax and
semantics.
 Both the called and calling program behave as if the partner program
were running on the same machine.
 RPCs are often used for client/server applications.
20
RPC Using Single Thread

21
RPC Using One Thread per Server

Categories of Thread Implementation
22
 User Level Thread (ULT)

 Kernel level Thread (KLT) also called:
 kernel-supported threads
 lightweight processes.

23
User-Level Threads
 All thread management is done by the application
 The kernel is not aware of the existence of threads

24
Kernel-Level Threads
 Kernel maintains context information for the process
and the threads
 No thread management done by application
 Scheduling is done on a thread basis
 Windows is an example of this approach

26
Combined Approaches
 Thread creation done in the user space
 Bulk of scheduling and synchronization of threads by the application
 The multiple ULTs from a single application are mapped onto
some (smaller or equal) number of KLTs
 Example is Solaris

27 Interprocess Communications

What is IPC?
28
 IPC mechanisms allow processes to communicate

and to synchronize their actions without sharing the
same address space.
 IPC mechanism in a distributed system should make

communication transparent.

Traditional IPC
29
 How do we pass information from one process to

another?
 Pipes, shared memory.
 How do we avoid race conditions and achieve
mutual exclusion?
 Mutexes, lock variables, semaphores.
 How do we schedule processes when dependencies
are present?
 Batch, interactive, real-time.

Distributed IPC
30
 How do we support communication over a network?

 How do we hide the distinction between local and remote
communication?
 How do we deliver information with minimum latency, maximum
throughput and minimum jitter?
 How do we shield one process from failures of another?
 How do we ensure security?

Distributed Communication
31
 All communication in distributed system is based on

low-level message passing as offered by the underlying
network.
 Process A builds a message in its own address space and

executes a system call that causes the operating system
to send the message over the network to process B.
What Do We Need?
32
 Good network infrastructure.

 Efficient protocol stack.
 Transport protocol to handle various types of data.
 Communication models.
 Security.

Network Requirements
33
 Ability to transfer any data type:

 Bulk, voice, video.
 Minimum latency, maximum throughput, minimum jitter.
 Error detection and correction:
 Physical medium is never error-free.
 Different types of networks:
 Local Area Networks (LAN)
 Metropolitan Area Networks (MAN)
 Wide Area Networks (WAN)

Asynchronous Transfer Mode
 Communication technology that uses high-bandwidth,
low-delay transport technology, and multiplexing
techniques.
 ITU(International Telecommunication Union) standard for
cell relay in which multiple service type (such as voice,

video, or data) are conveyed in fixed-length.
 ATM networks are connection-oriented.
 ATM Services:
 Constant/variable bit rate 34
Switching
35
 Packet Switching:
 No predefined paths, e.g. traditional LAN.
 Circuit Switching:
 Specific path set up for each connection, e.g. telephone networks.
 ATM Switching:
 Hybrid of packet and circuit switching.
 Multiple connections over a predefined path.

ATM Network Operation
36
ATM devices:
 ATM Switches.
 ATM endpoints, e.g. workstations, video
coders/decoders.
 User-Network Interface (UNI) & Network-Node
Interface (NNI).

Classes of Communication Protocols
37
 Four classes of communication protocols:

 Remote Operations (Client/Server, Request/Response)
 Bulk data management (File transfer protocol)
 One-to-many communication (Multi-/Broadcasting)
 Continuous Media (Video/Audio)
 The diversity of communication requirements in a distributed system

prohibits the use of a single transport protocol.

Remote Operations
38
 The most basic form of communication in distributed

systems.
 Process A (client process) sends a message to process B
asking it to do some work.
 Process B (server process) carries out work and returns a
message with the result.
 Client and server can be the same process.
 Return message can merely be ACK.

Bulk Data Transfer
39
 Very large request or response messages.

 Bulk data transfer can be viewed as a special form of remote operation.
 When data goes to the client, the operation can be viewed as a read operation.
 When data comes from the client, the operation can be viewed as a write
operation.
 Request/response protocols are very efficient.

One-to-Many Communication
40
 Services that use replication to tolerate failures.

 Large amounts of internal communication is needed to keep the replicas
consistent.
 It is important that this communication reaches all replicas in a well-
defined order.
 In practice, replication protocols are always multicast protocols.

Continuous Media
41
 Multimedia networks require low-latency and

constant-rate data transport for continuous media
and low-latency for “normal” data.
 ATM networks appear to be good at allowing the

mixture of these data types.

Fundamental Properties of Protocols
42
 Message delivery:
 At-least-once.
 At-most-once.
 Feedback:
 End-to-end application-level acknowledgement.
 Error report on failures.
 Low end-to-end latency.
 Support large request/response messages.

Communication Failures
43
 Networks exhibit failures that manifest themselves as

lost packets.
 If not all packets are lost, these failures can be corrected
using feedback:
 Acknowledgements, timeouts.
 Communication protocols cannot be made completely
reliable:
 Client cannot distinguish a server that went down from one
that has become disconnected.
Unresponsive Server
44
Client Process Server Process Client Process Server Process
Request Request
Response

Amnesia Failure
45
 A processor suddenly stops (crashes) and forgets all its state.

 It resumes operations from the initial state (reboots).
 At-most-once message delivery cannot be achieved:
 Aim for at-least-once message delivery.

Recovering From Failure
46
 Session management:
 Unique session identifier.
 Guaranteed at-most-once message delivery.
 End-to-end acknowledgement:
 No dependence on protocol stack.
 Positive feedback about delivery and response can only be provided by an end-to-
end application level acknowledgement.

Procedure Calls
47
 Procedure calls - more natural way to communicate:

 Every language supports them.
 Natural for programmers to use.
 Idea: Servers can export a set of procedures that can be called
by client programs
 Similar to module interfaces, class definitions, etc.
 Clients just do a procedure call as it they were directly linked with the
server.
 Under the covers, the procedure call is converted into a message
exchange with the server.
Implementing RPC
48
 No architectural support for making remote procedure

calls.
 Simulate it with available tools:
 local procedure calls and

 sockets for network communication.
 This simulation makes remote procedure call a language
level construct as opposed to sockets, which are an
operating system level construct:
 Compiler knows that remote procedure calls need special
code. CNSM6114 – Network Programming
Implementing RPC
49
 Trick:
 Create stub functions that make it appear to the user that the call is really
local.
 A stub function looks like the function that the user intends to call but
really contains code for sending and receiving messages over a network.

Functional Steps in RPC
1. Client procedure calls client stub in normal way
2. Client stub builds message, calls local OS
3. Client's OS sends message to remote OS
4. Remote OS gives message to server stub
5. Server stub unpacks parameters, calls server
6. Server does work, returns result to the stub
7. Server stub packs it in message, calls local OS
8. Server's OS sends message to client's OS
9. Client's OS gives message to client stub
10. Stub unpacks result, returns to client
50
Steps in RPC
2-8
51
Benefits
52
 Procedure call interface.

 Writing applications simplified:
 RPC hides all network code into stub functions.
 Application programmers don’t have to worry about details:
 Sockets, port numbers, byte ordering.
 Presentation layer in OSI model.
 RPC uses a message-based communication scheme to provide remote
service.
 RPC messages are well structured (no longer just packets of data):
RPC Model
53
 A server defines the server’s interface using an interface

definition language (IDL)
 The IDL specifies the names, parameters, and types for all client-
callable server procedures.
 A stub compiler reads the IDL and produces two stub
procedures for client and server:
 The server programmer implements the server procedures and links
them with the server-side stubs.
 The client programmer implements the client program and links it with
the client-side stubs.
 The stubs are responsible for managing all details of the remote
communication between client and server.
RPC Stubs
54
 A client-side stub looks to the client as if it were a callable server

procedure.
 A server-side stub looks to the server as if a client called it.
 The client program thinks it is calling the server (In fact, it is
calling the client stub).

 The server program thinks it is called by the client (In fact, it is
called by the server stub).

 The stubs send messages to each other to make the RPC happen
“transparently”.
Marshalling
55
 Marshalling is the packing of procedure parameters into a message

packet.
 The RPC stubs call type-specific procedures to marshal (or unmarshall)
the parameters to a call
 The client stub marshals the parameters into a message.
 The server stub unmarshalls parameters from the message and uses
them to call the server procedure.
 On return:
 The server stub marshals the return parameters.
 The client stub unmarshalls return parameters and returns them to the
client program.

Marshalling Goals
56
 Linearize the data structures for

transport in messages and
reconstructing the original data
structures at the other end.
 Convert data structures from the data

representation on the calling process to
that of the called process.
Transport Protocol
57
 Which one?
 Some implementations may offer only one (e.g. TCP).
 Most support several:
 Allow programmer (or end user) to choose.

Interface Definition Language (IDL)
58
 Allow programmer to specify remote procedure

interfaces (names, parameters, return values)
 Pre-compiler can use this to generate client and server
stubs:
 Marshaling code
 Unmarshaling code
 Network transport routines
 Conform to defined interface
 Similar to function prototypes
Writing an RPC Program
59
 Client code has to be modified:

 Initialize RPC-related options.
 Transport type.
 Locate server/service.
 Handle failure of remote procedure call.
 Server functions
 Generally need little or no modification.

Server-side
60
 Start server
 Server stub creates a socket and binds any available local port to it.
 Calls a function in the RPC library:
 svc_register to register program#, port #
 contacts portmapper (rpcbind on SVR4):
 Name server
 Keeps track of {program#,version#,protocol} port# bindings
 Server then listens and waits to accept connections.

Remote Logging, Electronic Mail, and File
Transfer

TELNET is a general-purpose
client/server application program.
Remote virtual terminal
One server supports multiple VTs.

Some Common Features of Telnet
• Telnet is on a single TCP connection to port 23
• Telnet connection is unencrypted
• So easy for eavesdropper!
• In most cases, telnet is a remote terminal. Each
character is transmitted in a separated packet
• The same is true for SSH login stage
• A feature that could be exploited for “timing
attack”.

Telnet Commands
• telnet longwood.eecs.ucf.edu (eecs email
server)
• setup a remote shell to the server
• It will be denied since most Unix servers
nowadays do not support telnet
• telnet longwood.eecs.ucf.edu 25
• Setup a TCP connection to port 25 (email
service)

SSH – Secure Shell
• Replacement of old unsecure Telnet program
• Both ends authenticate with each other
• Rely on public key cryptography
• Will introduce PK in last chapter
• All communication messages are encrypted
• SSH is used also as a secure tunneling channel for

other applications
• File transfer
• Port forwarding (such as X window)
• Virtual private network (VPN)
SSH Programs and Usages
• Many open source ssh client software
• http://en.wikipedia.org/wiki/Comparison_of_SSH_clients
• PuTTY
• SSH uses TCP connection on port 22

• Login methods:
• Password
• private key kept on client, public key stored
on server (come to this in later security chapter)

ELECTRONIC MAIL
One of the most popular Internet services is
electronic mail (e-mail). The designers of the
Internet probably never imagined the
popularity of this application program. Its
architecture consists of several components
that we discuss in this chapter.

MUA: mail user agent

When the sender and the receiver of an
e-mail are on the same system,
we need only two user agents.
MUA:Outlook Express, Netscape

Messenger, Mozilla Thunderbird,
Eudora, Foxmail,…….

FILE TRANSFER
Transferring files from one computer to

another is one of the most common
tasks expected from a networking or
internetworking environment. As a
matter of fact, the greatest volume of
data exchange in the Internet today is
due to file transfer.
FTP uses the services of TCP. It needs
two TCP connections.
The well-known port 21 is used for the

control connection and the well-known
port 20 for the data connection.

FTP

Distributed Objects Technologies: .NET and
73
CORBA

What is .NET?
74
 A generic term for the MS vision

 The successor to Windows DNA
 Sometimes applied to product names
 Such as Windows .NET Server
 A specific software framework
 Includes a common runtime
 Common across OS and dev language
 Includes baseline dev tools in an SDK
 Includes powerful dev environment
 Visual Studio .NET
.NET Workings
75
An evolution from COM/DCOM  Windows DNA  .NET

 Platform-independent
 Internet integration
 Security
Primary Components
 Common Language Infrastructure (CLI): specifications for a runtime
environment, including a common type system, base class library, and a
machine-independent intermediate code known as the Common
Intermediate Language (CIL) – MSIL.
 Common Language Runtime (CLR): Runtime environment to run any
CIL code that adheres to CLI specs usually through JIT compilation.
.NET Structure: CLR and Win32 Services
76
Same class library

C# VB J#... across all programming
languages
Enterprise Connects .NET to COM+

ASP.NET ADO.NET Services for transactional
components and other
enterprise services
CLR Connects .NET to data

providers, including XML
Active documents
MSMQ COM+ IIS WMI
Directory
Win32
Provides WebForms for
thin clients, plus web
services via HTTP
.NET Framework: More generally
77

78 CNSM6114 – Network Programming
Introduction to CORBA
79
 Common Object Request Broker Architecture (CORBA)

 A standard for software componentry.
 Created and controlled by the Object Management Group (OMG).
 Defines APIs, communication protocol, and object/service information models to enable
heterogeneous applications written in various languages running on various platforms to
interoperate  platform and location transparency for sharing well-defined objects across a
distributed computing platform.
 CORBA "wraps" code written in some language into a bundle containing additional information
on the capabilities of the code inside, and how to call it. The resulting wrapped objects can then
be called from other programs (or CORBA objects) over the network.
 CORBA can be considered as a machine-readable documentation format.
 Interface Definition Language (IDL) to specify the interfaces that objects will present to the
world.
 A "mapping" from IDL to a specific implementation language like C++ or Java. Standard
mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, and Python. There are also non-standard
mappings for Perl and Tcl implemented by ORBs
CNSM6114 written
– Network for those languages.
Programming
CORBA Architecture
80
Client Server
Java Object
C++ Object
Skeleton
Stub Object Adapter
IIOP
ORB ORB
Stub
 Provides interface between client object and ORB
 Marshalling: client invocation
 Unmarshalling: server response
Client Server
Java Object
C++ Object
Skeleton
Stub Object Adapter
IIOP
ORB ORB
CNSM6114 – Network Programming 81
Skeleton
 Provides iterface between server object and ORB
 Unmarshaling: client invocation
 Marshaling: server response
Client Server
Java Object
C++ Object
Skeleton
Stub Object Adapter
IIOP
ORB ORB
(Portable) Object Adapter (POA)
 Register class implementations
 Creates and destroys objects
 Handles method invokation
 Handles client authentication and access control
Client Server
Java Object
C++ Object
Skeleton
Stub Object Adapter
IIOP
ORB ORB
Object Request Broker (ORB)
 Communication infrastructure sending messages between objects
 Communication type:
 GIOP (General Inter-ORB Protocol)
 IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)
Client Server
Java Object
C++ Object
Skeleton
Stub Object Adapter
IIOP
ORB ORB
Example of CORBA Services
85
 Naming: Keeps track of association between object names and

their reference. Allows ORB to locate referenced objects
 Life Cycle: Handles the creation, copying, moving, and deletion
objects
 Trader: A “yellow pages” for objects. Lets you find them by the
services they provide
 Event: Facilitates asynchronous communications through events
 Concurrency: Manages locks so objects can share resources
 Query: Locates objects by specified search criteria

CORBA Application
86
1) Define interface using IDL

2) Compile interface
3) Implement interface
4) Instantiate server:
 Register object as a CORBA object
5) Instantiate client:
 Invoke CORBA object
 Example using a Java client and server

J2EE vs. .NET
87
 Cola vs. Pepsi

Upper Layers: Mohammed Abebe (PH.D)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Upper Layers: Mohammed Abebe (PH.D)

Uploaded by

Copyright:

Available Formats

CHAPTER 2

Mohammed Abebe (Ph.D)

 Introduction to Processes, Multitasking and Threads;

 Client-Server Network Programming

 Unicast, multicast, broadcast;

 e-mail and file transfer; ICMP, SMTP, POP3, IMAP, FTP

 Elements of CORBA, J2EE, CNSM6114and .NET

must progress in sequential fashion.

 Current activity including program counter, processor registers.

 Stack containing temporary data.

 Function parameters, return addresses, local variables.

 Heap containing memory dynamically allocated during run time.

 Program is passive entity, process is active

 One program can be several processes.

CNSM6114 – Network Programming

CNSM6114 – Network Programming

CNSM6114 – Network Programming

 Is a data structure that contains information associated with each

CNSM6114 – Network Programming

CNSM6114 – Network Programming

code section, data section, and other operating-system resources,

control. If a process has multiple threads of control, it can

 Switching between two threads takes less time

than switching processes

invoking the kernel.

 MS-DOS supports a single user process and a single

support one thread per process

CNSM6114 – Network Programming

 The ability of an OS to support multiple, concurrent paths of execution

CNSM6114 – Network Programming

CNSM6114 – Network Programming

 An RPC is a technique by which two programs, which may execute on

CNSM6114 – Network Programming

CNSM6114 – Network Programming

 User Level Thread (ULT)

CNSM6114 – Network Programming

CNSM6114 – Network Programming

CNSM6114 – Network Programming

CNSM6114 – Network Programming

CNSM6114 – Network Programming

 IPC mechanisms allow processes to communicate

 IPC mechanism in a distributed system should make

CNSM6114 – Network Programming

 How do we pass information from one process to

CNSM6114 – Network Programming

 How do we support communication over a network?

CNSM6114 – Network Programming

 All communication in distributed system is based on

 Process A builds a message in its own address space and

 Good network infrastructure.

CNSM6114 – Network Programming

 Ability to transfer any data type:

CNSM6114 – Network Programming

cell relay in which multiple service type (such as voice,

CNSM6114 – Network Programming

CNSM6114 – Network Programming

 Four classes of communication protocols:

 The diversity of communication requirements in a distributed system

CNSM6114 – Network Programming

 The most basic form of communication in distributed

CNSM6114 – Network Programming

 Very large request or response messages.

CNSM6114 – Network Programming