1. Programming Servers
Feb 2009
Tokyo-Honjo

2. 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)

3. 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 connection from a client executing the instruction
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.

4. 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 protocol.
It is important that both side follow this protocol in order not to block the communication and/or miss some data. This mean following the “turn taking” rules of sending to and receiving data 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

5. A Date Server
We will program now a date server for a computer which has no one
1) answer with the date in another socket
2) close the connection
Client
Date server 13
a) Create the server socket
b) start listening
DateServer
DateClient2

6. An Echo Server
We will program now an echo server for a computer which has no one
3) answer with the same
2) read line 4)
Client
Date server
1) accept 7
a) Create the server socket
b) start listening
Do 2 & 3 until client disconnects
EchoServer
EchoClient2

7. 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
keyboard
Bla bla
Talk Server
Talk client

8. Design of the programs is driven by the communication protocol
while (true)
read hostname from keybord
s=new Socket(host,x)
open writing to socket
while (true) {
read line from keyboard
write to socket
if (line.equals(“sayonara”))
break;
read line from socket
write line on screen }
Open server socket port =x
while(true) {
accept call
open reading from socket
while (true) {
read line from socket
if (line.equals(“sayonara”))
break;
write line on screen
read from keyboard
write to socket }
TalkServer
TalkClient

9. 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 (does not include static variables or references to local things such as files or sockets)
Unmarshaling
delivery
Marshaling

10. 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);
MyDate
ObjectServer
ObjectClient
Node
NodeSender
Nodereceiver

11. 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 files with other type of data (images, sounds executable programs)
NOTAS

12. Uploading files
The reciver (server) starts listening for requests to send (upload) files
Host & filename as parameters
2) Sender (client) connects
4) Send bytes
5) Write bytes in file
3) Read bytes from file
Repeat 3,4,5 until
all the file is transmitted
ArchEnviador.java
ArchRecibidor.java

13. Downloading files 2) Input filename from keyboard
1) Connect ) Send filename
4) Send bytes
5) Write bytes
3) Read bytes
Repeat 3,4,5 until
all the file is transmitted
ArchServidor.java
ArchCliente.java
This file server is very unstable !!!

14. A more robust version
This version uses 2 different sockets: one for the
“control” dilogue and another for the actual transmition.
It also uses the reading timeout
1) Sends filename
2) Answers OK (or not OK)
3) Opens another socket
4) Send file
ArchClienteRobust.java
ArchServidorRobust.java
See FTP Example

15. Servers with and without state
What is the 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
NOTAS

16. 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
NOTAS

17. 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

18. Possible sources for errors
The net may send the request two times (for example, if an acknowledge message 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 machines 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.
This was written, back in the 80’s. Now there are a lot of servers with state. People know better now how to develop them.

19. 1 An attempt of writing a file server with state
This implementation will server sequential text file
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 FileServerWithState.java & FileClientWithState.java
2 An example of a file server without state
This implementation will server random access files
It receives requests for reading/writing a certain number of bytes from/into a file
See FileserverNoState.java & FileClientNoState.java

20. 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 set of data 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
Situation with state:
The server stores temporarily the results until the client ends the session of queries.
System may allow a new query to be applied to the result set of the previous one
NOTAS

21. 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
Situation with state
The server stores information about the products a client has selected until the order is placed or the buying process aborted
NOTAS

22. 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:
For every transaction the client must identify itself again (user of client program must enter login + password)
Situation with state:
The server remembers the client has authenticated itself already registering the permissions it has
NOTAS

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

24. 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é

25. Access Controls
On a local file system it is only necessary to check the access rights of the file user 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 of its simplicity

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

27. Caracteristics of the NFS
Communication is implemented over RPC (first middleware for distributed systems) and is open. 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

28. Cache in NFS
NFS Cache on client side: results form read, write, getattr, lookup and readdir are stored locally an transferred to the server when the file is closed. 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, it will be 3-30 secs for files and for directories

29. The AFS Aims at 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

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

31. 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