Programming for information

communication systems

Programming of distributed application over TCP/IP networks

Yerevan, Sept.- Oct. 2014

Nelson Baloian,

Content0. Introduction (concepts of distributed systems)

1. TCP/IP client & server programming – Client programming:

– a simple client (date, echo) – a pop3 client – A SMTP client

2. Server programming (and their clients)– Simple client-server example with serializing example – File Servers: simple whole file iterative server (not secure)– Simple whole file robust server – Simple whole file concurrent server – Stateless random access file server – TCP/IP Chat with awareness – A simple extensible web server – Parallel downloading techniques – Awareness in a TC/IP peer to peer environment and the

latecomers problem

Content3. UDP programming

- simple UDP client-server example - a "ping" program –- multicasting - multicasting chat - awareness in a multicasting environment - broadcasting vs. multicasting

4. RMI Client-server programming - a simple example will be used to show: remiregistry,

concurrency automatic stub distribution - a sequential file server with state - Automatic teller machine example - RMI-based chat with awareness

5- Introduction to servlets and jsp- principles - parameters (from request and parameter file) - using forms - implementing state with cookies/sessions

6- JDBC

Evaluation

• Attending to classes (at least 80%)

• 3 homeworks

• Participation in classes

• Our webpage at http://www.dcc.uchile.cl/nbaloian/cc50h/2014/

• Final Exam

Schedule

• Mondays: 9:30 – 11:20• Wednesdays : 9:30 – 11:20• Firdays : 9:30 – 11:20• From Sept. 22 to Oct 20

How to follow the lectures

• During classes: – Download and run the examples by yourself– Keep the programs in your computer and write

comments (many do not have any)– Follow the class: I will ask you to tell me what do

the programs do

• After classes:– Read the lecture again,

Why distributed systems

- Share resources (25 years ago)- Communicate people (now)- Performance, scalability (always)- Fault tolerant systems (always)

Which distributed programs do I use?

1- Chat

2- email

3- p2p file sharing

4- web browser-server

5- database software

6- file server

Can you guess how were they developed ?

1- Programming language and resources used

2- Connection style

3- Communications architecture

4- Software architecture

5- Server design (if any)

Internet : two different ways to deliver a message to another application

The UDP: User Defined Package: like writing a letter

TCP or UDP

Applications’ programmers decide on this according to their needs

Every layer has the illusion of talking to the same one located at the other host

A SERVER

A CLIENT

A CLIENT

A CLIENT

4444

The UDP: User Defined Package: like writing a letterRead write sequence

UDP or TCP communication

Internet frames and addresses

electricpulses

Programming Communications in a TCP/IP Network

• At a low level (¿future “assembler of the communications”?)

• Based on the “sockets” & “ports” abstractions• Originally developed for BSD UNIX but now present in almost all

systems (UNIX, LINUX, Macintosh OS, Windows)• The destination of a message is determined by the computer’s IP

number and the port number • Every machine has 216 ports• The origin of the message is also a socket but most of the times the

port number is not important • Ports are associated to services (programs)

The 3 basic communication forms• UDP communication reflects almost what really happens

over the internet. An application sends a packet trough a socket addressed to a certain IP number and port. There should be another application on that host listening to packets coming to that port (which is agreed beforehand)

• TCP simulates a data flow. A client must establish a communication with the server before starting sending/receiving data. The server must be waiting for such request.

• Multicast fits well for group communication when the group is not well defined beforehand (spontaneous networking). It is also based in the sending of UDP packages but all “interested” applications may receive it. It does not require a central server

Protocols for communication• Every service is normally identified by a port

– Web: HTTP (port 80)– Mail: SMTP (port 25)– File transfer protocol: FTP (21)– telnet: 22/23

More common services ports at:http://www.chebucto.ns.ca/~rakerman/port-table.html

• Servers with/without Connection– connectionless style: UDP – connection-oriented style TCP

The SOCKET

A SERVER 1

When a server wants to start listening it must create a socketbound to a port. The port is specified with a number.

A SERVER 2

A SERVER 3

www.informatik.de

4444

3333

5555

If a client wants to communicate with server 1 should try to communicate with computer www.informatik.de through port 4444

UDP: communication with datagramsDATAGRAM: an independent, self-contained message sent over the internet whose arrival, arrival time and content are not guaranteed (like regular mail in some countries....)

A SERVER A CLIENT

4444

www.informatik.de

www.waseda1.jp

message

4444

Once a server is listening, the client should create a datagramwith the server’s address, port number and, the message

www.waseda2.jp

?

Sending datagrams with UDP protocol

Then it should open a socket and send the datagramto the internet. The “routing algorithm” will find the way to the target computer

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

?

Before the datagram leaves the client, it receives the address of the originating computer and the socket number

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

!

Sending datagrams with UDP protocol

Sending datagrams with UDP protocol

After the datagram is sent, the client computer may start hearing at the port created for sending the datagram if an answer from the server is expected

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

?

Sending datagrams with UDP protocol

The server can extract the client’s address and port number to create another datagram with the answer

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

answer

?

Sending datagrams with UDP protocol

Finally is sends the datagram with the answer to the “client”. When a datagram is sent there is no guarantee that it will arrive to the destination. If you want reliable communication you should provide a checking mechanism, or use ...

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

?

TCP: communication with data flow

With TCP a communication channel between both computers is built and a reliable communication is established between both computers. This allows to send a data flow rather tan datagrams.

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

?

TCP: communication with data flow

After the client contacts the server, a reliable channel is established. After this, client and server may begin sending data through this channel. The other should be reading this data: They need a protocol !!!!

A SERVERA

CLIENT

4444

www.informatik.de

3333

www.waseda2.jp

bla bla bla bla

TCP: How is data flow simulated ?

The internet itself works only with the datagram paradigm. Internet frames are may “get lost” (destroyed): For every frame delivered carrying a part of the data flow there is a confirmation!

Sending bla bla bla

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Ack 2nd bla

Sending 3rd bla

Ack 3rd bla

What if a message get lost ?The server waits a certain amount of time. If it does not receive any confirmation it sends the message again.

Sending bla bla bla

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Sending 2nd bla again

Ack 2nd bla

No confirmation !!!

LOST !!!

The Window for improving efficiencyThe transmitter will handle a set of not acknowledged packets

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Ack 2nd bla

Sending 3rd bla

Ack 3rd bla

What if messages arrive in disorder ?The receiver has a queue (buffer) of received messages.

Application (socket)

TCP or UDP Protocol: decision at the transport level

• What does it means for the programmer/designer: – By choosing a protocol programmer/designer decides about

reliability and speed. • TCP provides high reliability: data are only sent if the communication

was established. An underlying protocol is responsible for retranslating, ordering, eliminating duplicate packages

• UDP reflects just what the internet does with the packages: best effort delivery, no checking.

– quite different programming styles !!: • With TCP the data is sent a flow (of bytes, in principle) which can be

written, read as if they were stored in a file.

• With UDP the programmer must assemble the package and send it to the internet without knowing if it will arrive its pretended destination

When to use one or another

• Considerations – TCP imposes a much higher load to the network than UDP (almost 6

times)

– We can expect high package loss when the information travels trough many routers.

– Inside a LAN UDP communications may be reliable is there is not much traffic. Although with some congestion we can expect some packages to be lost inside the LAN

• In general, it is recommended especially for beginners (but also to skilled programmers) to use only TCP to develop distributed applications. Not only it is more reliable but the programming style is also simpler. UDP is normally used if the application needs to implement hardware supported broadcasting or multicasting, or if the application cannot tolerate the overload of TCP

Mark with a + the applications to use TCP and with a = those to use UDP

E-Mail Video conference

Temperature every second

Web server and client

Stock values every 5 seconds

The client-server paradigm(do you remember the WEB ?)

The web server

program

Webresources

request

answer

THE INTERNET

requestanswer

The web client program

1- The server opens a channel and starts listening to requests.

A SERVER

Webresources

THE INTERNET

A CLIENT

1 ?

2- A client who knows it, sends a request and waits for the answer

A SERVER

Webresources

THE INTERNET

A CLIENT

2

2

3- The server, analyses the request and answers properly according to the

protocol

A SERVER

Webresources

THE INTERNET

A CLIENT

3

3

This may involve the reading of a file

Why Client/Server ? It is a communication protocol model (listener/caller)

• TCP/IP does not provide any mechanism which would start running a program in a computer when a message arrives. A program must be executing BEFORE the message arrives in order to establish a communication (daemons).

• Is there really no other mean to communicate ?– Multicasting (but the sender does not know who is receiving and

in this case there is no dialogue)

• Most programs do not act as pure servers or client– It very frequent to have a server of o a certain program act as a

client of another

– Sometimes a group of programs are client and servers from each other at the same time!

Communication Architectures for Distributed Applications

• Servers as Clients– Programms do not behave as pure servers or as pure clients. For

example, a file server can ask another compter for a timestamt to register the last change of a file.

– When all application must behave at the same time as client and server we can organize the communication in two basic ways:

• Every application can open a communication channel with each other application (network configuration): P2P applications

• There is a commincation server and all applications open one communication channel with it (star configuration): multiple chat servers.

The Client-Server Model

Client

Client

Server 1

Server 2

Server 3

request

answer

Services Provided by Multiple Servers

Client

Client

Server 2

Server 3

Server 1

Proxy servers & caches

Client

Client

Proxy/cache

Server 2

Server 1

Peer-to-peer Applications (p2p)

Application+

Coordination

Application+

Coordination

Application+

Coordination

Network communication architecture

• Every application opens an exclusive channel qith each other application present in the session

• There may be up to n*(n-1)/2 channels open for n applications

• Advantages: – It avoids bottlencks in the communications

• Drawbacks: – All applications must be aware of all other taking part in the session – The dynamic is more complicated when managing consistency when

applications enter and quit the session

Star communication architecture

• The applications open a channel with the server and send their communication requests to the server. This server takes the message and forwards it to its final destination

• There are up to n channels open for n applications

• Advantages: – The managing og the communication parameters is more easy to manage

– The problem of incomming and outgoing of applications is more easy to tackle

• Drawbacks: – The server can get oveloaded

– The channels may get overloaded.

Replicated Architecutres

• Every application has a copy of the application and the data

• The modifications (data) are distributed to all participants in some way

• Synchronization is normally achieved by distributing the events, not the state of the data

• Problems with latecommers

• Communication architecture may be that of a star or network type

Replicated Architecture

Data

DataData

view

Data

Appl

Semi-replicated Architectures

• Data are kept centralized by a single application

• Every client mantains its own actualized view of the data

• There is a single data model, while the views and controllers are replicated

• Permits the use of different interfaces (browser)

• Synchronisation by events or by state

• Communication architecture normaly centralized (the data are located at the server)

Semi-replicated Architecture

Data

Data

Data

Centralized Architecture

• Data and view are mantained centralized

• Every client has a graphic server for displaying the view

• Synchonization by state (the view)

• Communications architecture centralized

• It provoques a big traffic of data over the network (the whole view is transmitted)

• Are frecuently of general use (like netmeeting)

Full centralized Architecture

view / commands

view / commands

Nowadays there is a lot of middleware which make distributed programming

much easier

Libraries for distributedprogramming (middleware)

RPC, CORBA, RMI

Goals of the Middleware

• Provide a framework for making development of distributed system easier

• Hide (encapsulate) communications details• Make distributing programming similar to

local programming• Standardization of communication

protocols and data format• This help comes not for free !!!

Web-Based Distributed Systems

• Applications talk to each other using HTTP protocol

• Trough port 80 (usually the only available)• Thin clients – Fat Servers• Use of Web and Application servers• The server is “extended” to implement new

services

J2EE Basic Architecture

Database ServerWeb Server

ApplicationServer

Client:Web Browser

Communication viaJDBC

HTML PagesServlets JSP pages

EJB