programming servers october 2003. programming the server what happens on the server when the client...
Post on 21-Dec-2015
223 views
TRANSCRIPT
Programming Servers
October 2003
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);
• 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, 555)–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 (why ?)
We will program now a date server for a computer which has no one
A Date Server
Date server 13 Client
1) Create the server socket 2) start listening
4) close the connection
3) answer with the date in another socket
DateClient2DateServer
We will program now an echo server for a computer which has no one
An Echo Server
Date server 7 Client
1) Create the server socket 2) start listening
3) Request a line
4) answer with the same
Do 3 & 4 until client disconnects or sends a line with ** EchoServer EchoClient2
Bla bla from keyboard
Talk client Talk Server
Something rather simple to start
Bla bla
• 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, everything the client user types in will be transmitted to the talk server and this will display it on the screenboard
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
} //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(“bye”))
break;
}
TalkClientTalkServer
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 untilall the file is transmitted
Uploading files1) 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 untilall the file is transmitted
Requesting files by their names
ArchServidor.java
ArchCliente.java
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 Handle Filename Position
1 AFile.txt 02 ADocument.doc 4563 AGAME.exe 384 Hola.java 128
• 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 SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Requirement to open XYZ
Response: file XYZ exists and ready
The server does not remember the former requirements
A SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Requirement: read from XYZ starting frombyte 0 , 50 bytes
Response: the content (byte array)
All information bust be provided again !
A SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Requirement: read from XYZ starting frombyte 50 , 50 bytes
Response: the content (byte array)
This may cause a lot of network traffic, especially if there are many
clients
A SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Requirement: read from XYZ, starting from byteN, 50 bytes
Response: the content (byte array)
Stateful Server: Manintains a table
A SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose 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 SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose 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 SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Req. 0, read 50
Response: the content
Pointer File Position
0 XYZ 100
1 ZXY 50
It is important to close the file
A SERVERA CLIENT
Open file XYZread first 50 byteswhile (not end of file XYZ)
read next 50 bytesclose file
?
Req. 0, read 50
Response: the content
Pointer File Position
0 XYZ 100
1 ZXY 50
Possible sources for errors• The net may send the request two times (if an ack does not arrive UDP)• 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
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
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
Model for the interface
• 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
The NFS
Application
Virtual System
SistLocal
ClientNFS
Virtual System
ServerNFS
SistLocal
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 Client’s 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 server’s 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 (Tmcliente = Tmserver). Normally t will be 3-30 secs for files and 30-60 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
LocalSist
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