Web technologies/2014-2015/Laboratory 1

From Wikiversity
Jump to navigation Jump to search

Communication architectures[edit | edit source]

  • Client-server (eg. Messenger, SETI@HOME) - centralized
  • Peer to peer (eg. Torrents, Cryptocurrency, Kazza) - decentralized
  • ...

About client server architectures[edit | edit source]

Most inter-process communication uses the client server model. These terms refer to the two processes which will be communicating with each other. One of the two processes, the client, connects to the other process, the server, typically to make a request for information. A good analogy is a person who makes a phone call to another person.

NOTE: The client needs to know of the existence of and the address of the server, but the server does not need to know the address of (or even the existence of) the client prior to the connection being established.

NOTE: Once a connection is established, both sides can send and receive information.

The system calls for establishing a connection are somewhat different for the client and the server, but both involve the basic construct of a socket i.e. one end of an inter-process communication channel. Each of the two processes must establish their own sockets.

The Internet usually relies on this kind of communication model.

In what follows we present the steps required for both client and server to create sockets and communicate through them

Client socket steps[edit | edit source]

	//Creating the client socket:
	Socket socket = new Socket ();

	//Binding to the local socket address:
	InetAddress localIpAddress = InetAddress.getByName ("");
	int localIpPort = 0;
	SocketAddress localSocketAddress = new InetSocketAddress (localIpAddress, localIpPort);
	socket.bind (localSocketAddress);

	//Connecting to the remote socket address:
	InetAddress remoteIpAddress = InetAddress.getByName ("localhost");
	int remoteIpPort = 20000;
	SocketAddress remoteSocketAddress = new InetSocketAddress (remoteIpAddress, remoteIpPort);
	socket.connect (remoteSocketAddress);

	//Receiving and/or sending data through inbound and outbound streams:
	BufferedReader reader = new BufferedReader (new InputStreamReader (socket.getInputStream ()));
	BufferedWriter writer = new BufferedWriter (new OutputStreamWriter (socket.getOutputStream ()));

	String request = "Hello";
	writer.write (request);
	writer.newLine ();
	// Do not forget to flush
        writer.flush ();

	// Reading the response
	String response = reader.readLine ();

	//Shutting-down the inbound and outbound streams:
	socket.shutdownInput ();
	socket.shutdownOutput ();

	//Closing the socket:
	socket.close ();

Server socket steps[edit | edit source]


	//Creating the server socket:
	ServerSocket socket = new ServerSocket ();

	//Binding to the local socket address -- this is the one the clients should be connecting to:
	InetAddress localIpAddress = InetAddress.getByName ("");
	int localIpPort = 20000;
	SocketAddress localSocketAddress = new InetSocketAddress (localIpAddress, localIpPort);
	socket.bind (localSocketAddress);

	while (true) {

		//For each connection accepting a client socket, and:
		Socket client = socket.accept ();

		// Starting a new Thread for each client
		new Thread () {
			public void run () {
				try {
					//Receiving and/or sending data;
		                        BufferedReader reader = new BufferedReader (new InputStreamReader (client.getInputStream ()));
					BufferedWriter writer = new BufferedWriter (new OutputStreamWriter (client.getOutputStream ()));
					// Reading the request
					String request = reader.readLine ();
					// Write the response
					String response = "Welcome";
					// Do not forget to flush!

					client.close ();
				} catch (Exception e) {
	//Closing the server socket;
	socket.close ();


TCP/IP[edit | edit source]

Set of protocols used for Internet communication (and other similar networks)

Its name comes from :

  • Transmission Control Protocol - TCP
  • Internet Protocol - IP

TCP is characterised by state; a message is always followed by a response. This in contrast with the UDP (User Datagram Protocol) protocol where there is no ensurance that a message has arrived at its destination.

It is composed of four layers: Link layer, Internet layer, Transport layer and Application layer. In contrast the OSI (Open System Interconnection) model is made up of 7 layers: Physical, Data, Network, Transport, Session, Presentation and Application layer.

TCP and UDP work at Transport level.

URI -- Uniform Resource Identifier[edit | edit source]

Used to identify resources. It is made up of the following subclasses:

  • URL - denotes a resource using the exact location by encoding the exact access method and parameters.
  • URN - denotes a resource by uniquely identifying the resource and not relating to its location.

URL Syntax[edit | edit source]

URL: http://<host>[:<port>]/[<resource>][?<query>]

URN Syntax[edit | edit source]

Specification: RFC 1630.



  \ /   \______________/\_________/ \_________/ \__/
   |           |             |           |        |
scheme     authority        path       query   fragment
   |   ______________________|_
  / \ /                        \

Design criteria[edit | edit source]

(Quoted from RFC 1630)

  • Extensible:
    • new naming schemes may be added later.
  • Complete:
    • It is possible to encode any naming scheme.
  • Printable:
    • It is possible to express any URI using 7-bit ASCII characters so that URIs may, if necessary, be passed using pen and ink.

HTTP[edit | edit source]

Is an application-level protocol for distributed, collaborative, hypermedia information systems. Its name comes from Hyper Text Transfer Protocol.

Lead to the creation of the World Wide Web (WWW) in 1990 by Tim Berners-Lee.

The HTTP/1.1 standard were released in June 1999. Amongst its features we enumerate: persistent connections, pipelining, virtual hosting, chunked transfer.

Actors[edit | edit source]

  • User agent:
    • Is a client application which contacts a server on behalf of the user:
      • download client
      • web browser
      • web spider
  • Server:
    • Is a server application which receives requests and answers them
  • Proxy:
    • Is a server application that receives requests and decides to serve them itself, or pass them to the real server, or through a chain of servers. The requests and responses transferred may be modified by it:
      • caching proxy;
      • anonymizing proxy;
      • transparent proxy;
      • reverse proxy;

Protocol[edit | edit source]

Specifications: RFC 2616.


[method] [resource] [version]<CRLF>
[header]: [value]<CRLF>

Example request:

GET /index.html HTTP/1.1<CRLF>
Host: www.example.com<CRLF>


[version] [status] [message]<CRLF>
[header]: [value]<CRLF>

Example response:

HTTP/1.1 200 OK<CRLF>
Date: Mon, 23 May 2005 22:38:34 GMT<CRLF>
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux)<CRLF>
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT<CRLF>
Etag: "3f80f-1b6-3e1cb03b"<CRLF>
Accept-Ranges: bytes<CRLF>
Content-Length: 438<CRLF>
Connection: close<CRLF>
Content-Type: text/html; charset=UTF-8<CRLF>
<Content ...>

Request methods[edit | edit source]

HEAD - used to retrieve only the header of the response. Useful for requesting the meta-information without the actual content.

GET - Used to retrieve both the meta-information and the content of the resource. It is the most used method. It should have no side-effects. (It should be a safe method)

POST - Used to send some data to be processed. (For example as result of filling and sending some user forms)

PUT - used to replace a resource

DELETE - used to remove a resource

TRACE - used to debug or diagnosticate a request. Each server should echo the received request

OPTIONS - used to identify the capabilities of the server


Status codes[edit | edit source]

  • 2xx -- Success
    • 200 -- OK
    • 201 -- Created
    • 202 -- Accepted
  • 3xx -- Redirection
    • 301 -- Moved permanently
    • 302 -- Moved temporarily
  • 4xx -- Client error
    • 400 -- Bad request
    • 401 -- Unauthorised
    • 403 -- Forbidden
    • 404 -- Not found
    • 405 -- Method not allowed
  • 5xx -- Server error
    • 500 -- Internal server error
    • 501 -- Not implemented

Headers[edit | edit source]

Headers are important to HTTP, as they define some important characteristics of the connection and data sent or received.

  • Accept
Accept: text/plain
  • Accept-Charset
Accept-Charset: iso-8859-5
  • Accept-Encoding
Accept-Encoding: compress, gzip
  • Accept-Language
Accept-Language: da
  • Content-Encoding
Content-Encoding: gzip
  • Content-Language
Content-Language: da
  • Content-Length
Content-Length: 348
  • Content-Type
Content-Type: text/html; charset=utf-8
  • Host
Host: www.w3.org
  • If-Modified-Since
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
  • Last-Modified
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
  • Server
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
  • User-Agent
User-Agent: Mozilla/5.0 (Linux; X11; UTF-8)


API[edit | edit source]

Miscellaneous - connecting to remote machines through digital certificates[edit | edit source]

During the following labs you could require to connect to remote machines in order to publish your web pages and projects. Because authentication requires you to enter each time a username and password bellow is an easier way which is base on digital certificates. After following the instructions bellow you will be able to connect from any Linux machine having the generated private key:

  • cd ~/.ssh
  • ssh-keygen -t rsa
  • choose no passphrase when asked and accept the default filename of id_rsa
  • scp id_rsa.pub <user>@<yourhost>:.ssh/authorized_keys
  • provide your password when asked and that’s the last time you’ll have to do it!

If you wish to connect to several remote machines you can reuse the created id_rsa.pub and copy it on each of them as indicated above.

Exercises[edit | edit source]

  • Create a simple chat application such that:
    • you have one client and one server
    • the client (human user) must send messages to the server (computer) which in turn will respond to them automatically:
      • For example:
        • client: hello
        • server: hi! what's your name?
        • client: John
        • server: nice to meet you John!
        • client: ...
  • Implement a simple HTTP client application which (bonus - for lab 3):
    • takes on the command line an URL as an argument
    • parses the given URL to obtain all the needed information, or uses the default values for the missing information
    • contacts the specified web server
    • requests the resource
    • interprets the received status line
    • prints the response body
    • handles the most common errors that can be encountered

IMPORTANT: It is forbidden to use an existing HTTP library or class; you should implement the HTTP protocol yourself. You may use the URL class for parsing the argument. HINT: Use a socket connection to retrieve data (client).

Gabriel Iuhasz , 2019-10-08, iuhasz.gabriel@e-uvt.ro