Programming Servers June 2004. Programming the Server What happens on the server when the client tries to establish a rendezvous ? The server starts listening.

Slides:



Advertisements
Similar presentations
COS 461 Fall 1997 Network Objects u first good implementation: DEC SRC Network Objects for Modula-3 u recent implementation: Java RMI (Remote Method Invocation)
Advertisements

Distributed System Structures Network Operating Systems –provide an environment where users can access remote resources through remote login or file transfer.
Remote Procedure Call (RPC)
Remote Procedure Call Design issues Implementation RPC programming
Tam Vu Remote Procedure Call CISC 879 – Spring 03 Tam Vu March 06, 03.
CS-550: Distributed File Systems [SiS]1 Resource Management in Distributed Systems: Distributed File Systems.
Programming Servers Version Programming the Server What happens on the server when the client tries to establish a rendezvous ? The server starts.
A CHAT CLIENT-SERVER MODULE IN JAVA BY MAHTAB M HUSSAIN MAYANK MOHAN ISE 582 FALL 2003 PROJECT.
1 Java Networking – Part I CS , Spring 2008/9.
CS490T Advanced Tablet Platform Applications Network Programming Evolution.
Other File Systems: AFS, Napster. 2 Recap NFS: –Server exposes one or more directories Client accesses them by mounting the directories –Stateless server.
Programming Applets How do Applets work ? This is an HTML page This is the applet’s code It has a link to an applet.
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) cec.uchile.cl Módulo ECI - 11: Fundamentos de Redes de Computadores.
1 Programming Section 9 James King 12 August 2003.
I/O Hardware n Incredible variety of I/O devices n Common concepts: – Port – connection point to the computer – Bus (daisy chain or shared direct access)
Inter Process Communication:  It is an essential aspect of process management. By allowing processes to communicate with each other: 1.We can synchronize.
Programming Servers October Programming the Server What happens on the server when the client tries to establish a rendezvous ? The server starts.
An Introduction to Internetworking. Why distributed systems - Share resources (devices & CPU) - Communicate people (by transmitting data)
© Lethbridge/Laganière 2001 Chap. 3: Basing Development on Reusable Technology 1 Let’s get started. Let’s start by selecting an architecture from among.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
An Introduction to Internetworking. Algorithm for client-server communication with UDP (connectionless) A SERVER A CLIENT Create a server-socket (listener)and.
Implementing a concurrent file server (as an extension of Thread) Define a new Class as an extension of the Thread class which has a socket as Object variable.
NFS. The Sun Network File System (NFS) An implementation and a specification of a software system for accessing remote files across LANs. The implementation.
1 Network File System. 2 Network Services A Linux system starts some services at boot time and allow other services to be started up when necessary. These.
File Systems (2). Readings r Silbershatz et al: 11.8.
DESIGN AND IMPLEMENTATION OF THE SUN NETWORK FILESYSTEM R. Sandberg, D. Goldberg S. Kleinman, D. Walsh, R. Lyon Sun Microsystems.
Distributed File Systems Sarah Diesburg Operating Systems CS 3430.
TCP Sockets Reliable Communication. TCP As mentioned before, TCP sits on top of other layers (IP, hardware) and implements Reliability In-order delivery.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Distributed File Systems Steve Ko Computer Sciences and Engineering University at Buffalo.
Process-to-Process Delivery:
TCP/IP protocols Communication over Internet is mostly TCP/IP (Transmission Control Protocol over Internet Protocol) TCP/IP "stack" is software which allows.
Networked File System CS Introduction to Operating Systems.
Distributed Systems. Interprocess Communication (IPC) Processes are either independent or cooperating – Threads provide a gray area – Cooperating processes.
Distributed File Systems Overview  A file system is an abstract data type – an abstraction of a storage device.  A distributed file system is available.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 3: Operating-System Structures System Components Operating System Services.
Li Tak Sing COMPS311F. Case study: consumers and producers A fixed size buffer which can hold at most certain integers. A number of producers which generate.
1 Chap8 Distributed File Systems  Background knowledge  8.1Introduction –8.1.1 Characteristics of File systems –8.1.2 Distributed file system requirements.
The InetAddress Class A class for storing and managing internet addresses (both as IP numbers and as names). The are no constructors but “class factory”
CE Operating Systems Lecture 13 Linux/Unix interprocess communication.
A Low-bandwidth Network File System Athicha Muthitacharoen et al. Presented by Matt Miller September 12, 2002.
Jinyong Yoon,  Andrew File System  The Prototype  Changes for Performance  Effect of Changes for Performance  Comparison with A Remote-Open.
CSC 480 Software Engineering Socket. What is Socket? A socket is one end-point of a two-way communication link between two programs running on the network.
Remote Procedure Calls CS587x Lecture Department of Computer Science Iowa State University.
Information Management NTU Distributed File Systems.
GLOBAL EDGE SOFTWERE LTD1 R EMOTE F ILE S HARING - Ardhanareesh Aradhyamath.
EE324 INTRO TO DISTRIBUTED SYSTEMS. Distributed File System  What is a file system?
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
4P13 Week 9 Talking Points
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Changing the way of designing distributed applications Communication oriented design: FIRST design the communication protocol for the distributed system.
Distributed File Systems Questions answered in this lecture: Why are distributed file systems useful? What is difficult about distributed file systems?
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
Distributed Systems: Distributed File Systems Ghada Ahmed, PhD. Assistant Prof., Computer Science Dept. Web:
Distributed Computing & Embedded Systems Chapter 4: Remote Method Invocation Dr. Umair Ali Khan.
DISTRIBUTED FILE SYSTEM- ENHANCEMENT AND FURTHER DEVELOPMENT BY:- PALLAWI(10BIT0033)
Distributed File Systems
MCA – 405 Elective –I (A) Java Programming & Technology
File System Implementation
Process-to-Process Delivery:
Distributed File Systems
Distributed File Systems
DESIGN AND IMPLEMENTATION OF THE SUN NETWORK FILESYSTEM
Distributed File Systems
Chapter 15: File System Internals
An Introduction to Internetworking
An Introduction to Internetworking
Programming Servers Feb 2009 Tokyo-Honjo.
Process-to-Process Delivery: UDP, TCP
Implementing a concurrent file server (as an extension of Thread)
Presentation transcript:

Programming Servers June 2004

Programming the Server What happens on the server when the client tries to establish a rendezvous ? The server starts listening to requests on a ServerSocket After accepting the request the resulting connection is attached to another (normal) socket (same type as client’s socket)

Sockets at the Server Side (1) The server should start by creating a server socket bound to a certain port according to the protocol of the service. ServerSocket listening; listening = new ServerSocket(5555); (or ServerSocket(portnumber, queueLength) This will create the socket but the server is still not listening. To do this we should apply the following method to the socket: Socket toClient = listening.accept(); This sentence works the following way: –accept blocks the execution of the program until there is a petition for a rendezvous from a client (with calling = new Socket(host, 5555) –When the requirement arrives, a TCP connection is established between the two computers. The client receives in its socket one end of this link and the server the other. The server side’s socket (from the Socket class) is chosen conveniently by the system

Sockets at the Server Side(2) At the server side we can apply the same methods as we did at the client side. Particularly we may need to open an input and an output data stream. After this, the server should implement the communication protocol which was established and published (by any other possible mean). It is important that both side follow this protocol in order not to block the communication and/or miss some data. This mean nothing else than following the “turn taking” rules of writing to and reading from the socket and the format of the data to be exchanged. Note that the server socket (and port) at which the server was originally listening to requests is not used anymore. This is a design issue

Something rather simple to start The TalkServer waits for someone wishing to communicate The TalkClient asks for a host name and tries the redezvous After the communication is set up, the client start sending a line and the server answers. This is done until one of them sends the word “sayonara”. keyboard Talk client Talk Server Bla bla keyboard

Schema of both programms Open server socket port =4444 While(true) { accept call open reading from socket while (true) { read line from socket if (line.equals(“bye”)) break; write line to screen read from keyboard write to socket } //end of the call } s=new Socket(args[0],4444) open writing to socket while (true) { read line from keyboard write to socket if (line.equals(“sayonara”)) break; read from socket write to screen } TalkClient TalkServer

Transmitting Objects via TCP Transmission: marshalling, delivery & unmarshalling. The key for this is the Object Serialization: convert the into a representation which can be transmitted across the net (String) All native Java Objects are serializables. For user defined objects it is necessary to write implements Serializable in their definition (this does not include static variables or references to local things such as files or sockets)

Transmitting Objects via TCP The classes which allows the transmit: –ObjectInputStream readObjetct() –ObjectOutputStream writeObject() The user can change the “standard” serialization mechanism by declaring implements Externalizable This means, the user must implement –void writeExternal(ObjectOutputStram o) –void readExternal(ObjectInputStream i); ObjectServerObjectClientMyDate

Sockets: File transfer We will now develop programs for transmitting files In the first case, the program receiving the file starts listening for someone who wants to upload a file The sender knows where (hostname and port number) the server is listening and sends a rendezvous request The data transfer is done at the byte level in order to allow the transfer of non textual files

2)The sender tries a rendezvous with receiver 4) Send bytes 3) Read bytes from file5) Write bytes in file Repeat 3,4,5 until all the file is transmitted Uploading files 1)The reciver starts listening for Requests to send (upload) files ArchRecibidor.java ArchEnviador.java

Version 2 Requesting files The file server –Starts listening for requests on a “known” port –When a request is accepted, a string corresponding to a filename is read – Opens locally a file with this name, reads it and sends it to the client (byte-wise) The file client –Tries a rendezvous with the server –Reads a filename from keyboard and send it to the server – Reads bytes from socket and write them to a file

1) Filename from keyboard 2) Request file 4) Send file 3) Read File5) Write file Repeat 3,4,5 until all the file is transmitted Requesting files by their names ArchServidor.java ArchCliente.java This file server is very unstable !!!

1) Sends filename 4) Send file 2) Answers OK (or not OK) 3) Opens another socket A more robust version ArchClienteRobust.java ArchServidorRobust.java

Servers with or without state ? What is a state of a server ? –The “state” is the information that servers keep about the interaction has occurred with the clients What for is it used ? –Generally it will make the the management of the dialogue more efficient event in the case small amount of information is kept and maintained: it will reduce the amount of information that has to flow between client and server to accomplish a certain task –Answers from the server will be faster Why is it generally avoided ? –Its a source for errors: messages from the client may get lost, arrive duplicates, or array in disorder. Clients can crash and reboot, which may cause in certain cases the information kept on the servers to be erroneous, and also their responses

An example of using state for file transfer The file server should waits for a client request. It accepts 2 types of commands from the client: reading from and writing into a file. The sever executes this command and returns the outcome of the operation to the client Situation without maintaining a state: –For reading, the client must always specify the name of the file, position in the file to start reading and the number of bytes (lines) to read. –For writing, the client must provide the name of the file, the position in the file to start writing and the data that will be written

Situation with state When the client opens a file an entry is created in the table. The entry has a file handle and the current position for reading/writing (initially 0). The client receives the handle as response. When the client wants to read data from the file, it just sends the handle and the number of bytes (lines). This is used by the server in order to know exactly which bytes to read. It has to change the position value When the client wants to write data on a file it provides the handle and the data. The server uses this and the table informatio to update the file When the clients closes a file is has to send a message in order to delete the entry from the table

The stateless server for remote files A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Requirement to open XYZ Response: file XYZ exists and ready

The server does not remember the former requirements A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Requirement: read from XYZ starting from byte 0, 50 bytes Response: the content (byte array)

All information bust be provided again ! A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Requirement: read from XYZ starting from byte 50, 50 bytes Response: the content (byte array)

This may cause a lot of network traffic, especially if there are many clients A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Requirement: read from XYZ, starting from byte N, 50 bytes Response: the content (byte array)

Stateful Server: Manintains a table A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Req. open XYZ Response: file pointer for XYZ Pointer file Pos 0 XYZ 0 1 ZXY 50

The information which clients has to prive is lesser A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Req. 0, read 50 Response: the content Pointer File Position 0 XYZ 50 1 ZXY 50

The information in the table must be updated A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Req. 0, read 50 Response: the content Pointer File Position 0 XYZ ZXY 50

It is important to close the file A SERVER A CLIENT Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file ? Req. 0, read 50 Response: the content Pointer File Position 0 XYZ ZXY 50

Possible sources for errors The net may send the request two times (if an ack does not arrive) The client program may crash and reboot The client computer crashes before it can “close” the file Another client may connect to the same socket (UDP) In a real internet network, where mashines can crash and reboot, and the messajes may get lost, duplicated, or in a incorrect order, to maintain a fault tolerant server with state may be extreamly difficult.

1 An attempt of writing a file server with state This implementation will server sequential text file (can be easily changed) It receives requests for opening a file for reading or writing, read next line, write line. The “state” is stored in a hashtable which contains objects of the classes BufferedReader and PrintWriter See 2 An example of a file server without state This implementation will server random access files (can be easily changed) It receives requests for reading/writing a certain number of bytes from/into a file See fileservernostate.java FileServerWitState.java FileServerNoState.java NoStateClient.java

Another example: a database query The client makes a query on a database. In the first query the client gets too many results and wants to refine the query making another over the results obtained in the first one. Situation without storing state: –The server must send the whole results to the client –The client should be able to make queries locally or send the second query and the results of the first one

Another example: The shopping cart The server waits for a client. The client search for products and selects them. The client moves between searching and selecting activities. Situation without state: –The whole list of selected items must be transmitted between client and server

Another example: the ATM The server asks the client to identify himself with login name and password in order to make a set of transactions and/or queries Situation without state: –Forevery transaction the client must identify herself again

Architecture of a generic file server Client Module Aplication Directory service Flat file service

Components Flat File Service: Implements the operations which work directly on the files. It uses a Unique File Identifier (UFID). A new one is generated for each new file Directory Services: is a FFS client, provides a mapping between the UFID and the textual names of the files. It also porvides the necessary functions for managing directories and obtain UFID.Directories are stored as plain files. Client module: Runs in every clinet computer, integrates and extends the FFS and DS operations in an interface application used by programmers. Contains information for localizing files over the network. Provides efficiency by implementing a caché

A model for an FFS interface read(FileId, i, n) : attempts to read up to n bytes from a file starting from the byte in the position i. write(FileId, i, Datos): writes a data sequence starting from the position i into the specified file create() : creates a new file (empty) and returns its UFID delete(FileId) : deletes the file getAttributes(FileId) : returns a structure containing the file attributes setAttributes(FileId, attr) : sets the file attributes according to what is stored in the structure

A Model for Directory Services Lookup(Dir, File) localises the name of the file in the directory UFID AddName(Dir, Name, File) If Name was not in the directory, the pair(Name,File) is added modifying the corresponding file UnName(Dir, Name) the pair (Name, file) is deleted from the directory getNames(Dir) turns the list of names in the directory

Access Controls On a local file system it is necessary check the access rights of the file user only when it is opened and the rights are kept until the file is closed On a distributed system the checking are made at the server side. There are two strategies used in order to keep the server stateless: –The checking is done when the filename is converted to the UFID and the result is packed as a “capacity” which is returned to the client. The client uses this capacity for each further access. –The checking of the user’s rights is made every time the file is accessed. The second one is the most used (in NFS & AFS) because its simplicity

The NFS Application Virtual System Sist Local Client NFS Virtual System Server NFS Sist Local

Caracteristics of the NFS Communication is implemented over RPC and is open. Resides in the server’s kernel The identification of the files is by file handlers containing following information: Filesystem identifier i-node number or file i-node generation number The “state” is kept in the client in a v-node Client authentication is done in every access.Client provides ID and group ID Flat file & directory services are integrated The mount service provides a link to a remote system

Cache in NFS Unix provides standard Cache mechanisms: buffer cache, read ahead, delayed write NFS Cache on server side: data for writing are stored in the cache memory and are written when a commit takes place (buffer full or closing the file) NFS Cache on client side: results form read, write, getattr, lookup and readdir are stored locally. This can introduce some inconsistencies with the versions stored at the different clients’ machines because writings in one client are not distributed at the moment to the others. Clients are responsible for maintaining their caches updated. This is done with the help of timestamps: –Tc= time of last synchronization of the cache, –Tm= time of modification –At a certain time T the cache will be still valid if (T - Tc < t) o (Tm cliente = Tm server ). Normally t will be 3-30 secs for files and for directories

The AFS Aims to a better performance in situations of scalability Principles –Whole-file serving: the content of the whole file is transferred to the client (even if the client has requested a small part of it) –Whole-file caching: The file transferred are stored in the local cache memory. The cache is almost permanent. Procedure –When the client opens a remote file, the whole content is ttransferred if it was not there already –Read/write operation are done locally –With a close, a copy of the file is transmitted to the server

The AFS Architecture Application Unix Kernel Local Sist Venus Vice Unix Kernel

Consistency of the Cache Every time a file is transmitted from the server to a client a callback promise is provided which guarantees that if other client modifies the file, this one will be notified The callback status can be either valid or cancelled When the file is transferred to the client the callback is put on valid. When a callback is received from the server (another client did modify the file) the callback promise is put on cancelled Every time the client wants to open a file, it searches it first in the cache. It if is there the callback promise status is looked, if it is still valid, the cache is used by the client, if it is not there or the callback is cancelled, a new version is transferred from te server If the client’s computer reboots,it asks for a timestamp for every file in the cache to the server. If it is consistent with the local timestamp the callback is put on valid, if not on cancelled