Title: ClientServer Communication EEE466 Reference: CDK00 chapter 4
1Client-Server CommunicationEEE466Reference
CDK00 chapter 4
2Client-Server CommunicationSockets
3UDP Client
import java.net. import java.io. public class
UDPClient public static void main(String
args) // args give message contents and
destination hostname DatagramSocket aSocket
null try aSocket new DatagramSocket()
byte m args0.getBytes() InetAddre
ss aHost InetAddress.getByName(args1) int
serverPort 6789
DatagramPacket request
new DatagramPacket(m,args0.length(),
aHost, serverPort) aSocket.send(request)
byte buffer
new byte1000 DatagramPacket reply new
DatagramPacket(buffer, buffer.length) aSocket
.receive(reply) System.out.println("Reply "
new String(reply.getData())) catch
(SocketException e)System.out.println("Socket "
e.getMessage()) catch (IOException
e)System.out.println("IO " e.getMessage())
finally if(aSocket ! null) aSocket.close()
4UDP Server
import java.net. import java.io. public class
UDPServer public static void main(String
args) DatagramSocket aSocket
null try aSocket new
DatagramSocket(6789) // create socket at
agreed port byte buffer new byte1000
while(true) DatagramPacket request new
DatagramPacket(buffer, buffer.length)
aSocket.receive(request)
DatagramPacket reply new DatagramPacket(reque
st.getData(), request.getLength(),
request.getAddress(), request.getPort())
aSocket.send(reply) catch
(SocketException e)System.out.println("Socket "
e.getMessage()) catch (IOException e)
System.out.println("IO " e.getMessage()) f
inally if(aSocket ! null) aSocket.close()
5TCP Client
import java.net. import java.io. public class
TCPClient public static void main (String
args) // arguments supply message and
hostname Socket s null try int
serverPort 7896 s new Socket(args1,
serverPort) DataInputStream in new
DataInputStream( s.getInputStream()) DataOutpu
tStream out new DataOutputStream(
s.getOutputStream()) out.writeUTF(args0)
// UTF is a string // encoding see Sn.
4.4 String data in.readUTF() // read a
line of data //from the
stream System.out.println("Received " data)
catch (UnknownHostException
e)System.out.println("Socket"e.getMessage())
catch (EOFException e)System.out.println("EOF"
e.getMessage()) catch (IOException
e)System.out.println("readline"e.getMessage())
finally if(s!null) try s.close() catch
(IOException e) System.out.println("close"
e.getMessage())
6TCP Server
import java.net. import java.io. public class
TCPServer public static void main (String
args) try int serverPort 7896 // the
server port ServerSocket listenSocket new
ServerSocket(serverPort) while(true)
Socket clientSocket listenSocket.accept()
Connection c new Connection(clientSocket)
catch(IOException e) System.out.println(
"Listen socket"e.getMessage()) class
Connection extends Thread DataInputStream
in DataOutputStream out Socket
clientSocket public Connection (Socket
aClientSocket) try clientSocket
aClientSocket in new DataInputStream(
clientSocket.getInputStream()) out new
DataOutputStream( clientSocket.getOutputStream())
this.start() catch(IOException e)
System.out.println("Connection"e.getMessage())
public void run() try // an echo
server String data in.readUTF() // read a
line of data from the stream out.writeUTF(data)
catch (EOFException e)System.out.println("EO
F"e.getMessage()) catch(IOException e)
System.out.println("readline"e.getMessage())
finally try clientSocket.close() catch
(IOException e)/close failed/
7Client-Server CommunicationRPC/RMI
- typically the client is requesting that the
server perform some service - normal pattern
- server invokes GetRequest and blocks until a
request arrives - server blocking receive
- client invokes DoOperation on server and blocks
waiting for reply - client asynchronous send, followed by blocking
receive - server performs operation, invokes SendReply, and
invokes GetRequest again - server unblocks, performs operation,
asynchronous send, followed by blocking receive - client unblocks, continues
8Specification of the Operations
- In pseudo-Java
- Message DoOperation(PortId server, Message msg)
- the returned message is the result of SendReply
- blocking
- Message GetRequest(PortId server)
- acquires a request message
- blocking
- void SendReply(PortId client, Message msg)
- sends a reply message
- interface Message
- MessageType type // request or reply
- int requestId // matches replies to requests
- int methodId // method to execute
- Object arguments // flattened list
9Delivery Failures
- In the general case
- messages are occasionally dropped by senders,
receivers, and the network - networks may become partitioned
- processes may fail
- not generally distinguishable from network
failure - typically assume failure after N requests
choosing a good N is a hard problem - received data is corrupted
- To account for this, DoOperation should have a
timeout associated with it other steps are
necessary
10Possible Exchange Protocols
- Looked at Request-Reply
- Three widely used variants
- Request
- no value to be returned
- no confirmation of operation is required
- Request-Reply
- used for most client-server communications
- reply regarded as acknowledgement from server
- next request regarded as acknowledgement from
client - Request-Reply-Acknowledge
- acknowledgements include requestIds receipt of a
requestId implies receipt of all lower-numbered
requestIds - losing an acknowledge message is harmless
11Timeouts
- Possible options on timeout of DoOperation
- return with error indication
- relies on application-level interpretation
- not appropriate if operation must be redone,
since the new attempt will have a different
requestId (possible source of duplicate requests) - multiple retry
- re-invokes DoOperation with same message until
success or reasonably certain problem due to
server failure - returns with server failure indication (throws
Exception)
12Duplicate Requests
- Since client may retransmit requests, server may
receive duplicates - e.g., server may be slow processing a request,
exceeds client timeout, client retries - with requestIds globally unique, can discard
duplicates
13Lost Replies
- If a server has already sent a reply when it
receives a duplicate, it may need to resend - cause may be lost reply message
- resending may require recomputing original
request - if operation is x7 this poses no problem
- if operation is x1 recomputing the request will
lead to incorrect values of x - recomputation is only allowable when the
operations are idempotent - an idempotent operation is one that can be
performed repeatedly with the same effect as if
it had been performed exactly once - Servers with only idempotent operations can
recompute duplicates
14History
- When a server cannot safely recompute operations,
it can use a reply history - record of reply messages that have been
transmitted - identifies requestId, message, client identifier
- Main issue is storage cost require a mechanism
to delete histories that are no longer required - if clients make only one request at a time,
receipt of next (new) request is acknowledgement
of previous - history can be erased up to new request, for this
client - can also use request-reply-acknowledge
- if many clients, storage requirement may be large
- problematic when client disappears without
acknowledging last request (Always happens in
request-reply protocol. Why?)
15Next Class Group Communication