Client/server

The (simple) Client/Server Connection using Stream Sockets: The Server 5 steps to building the server 1.Create a ServerSocket object registers an available TCP/IP port and a maximum queue length : ServerSocket server=new ServerSocket(port#,queuelen); This is called the handshake point. If the queue is full the connection is refused. The process is known as “binding a server to a port”. Only one application at a time can be bound to a particular port.

Simple Server continued: Step 2 2. The server listens, or “blocks” for a client connection: Socket connection =server.accept(); The socket connection makes possible interaction with the client via I/O streams. The server interacts with a client at a different port than the handshake point, which makes possible multi-threaded servers (ie.,after connection is established, the server can spawn a thread to process this client and go on listening for another.

Simple Server continued: Step 3 3. The server gets I/O connections associated with the client socket. I/O across the connection is not really much different than other java i/o. ObjectInputStream input = new ObjectInputStream(connection.getInputStream()); ObjectOutputStream output = new ObjectOutputStream(connection.getOutputStream()); The server’s output stream is the client’s input stream, and visa versa.

Simple Server continued 4. Process the connection – this phase is application-specific and might involve a single message being sent, complicated objects being exchanged, a loop, whatever. 5. Close the connection by invoking close() method on the streams.

The (simple) Client/Server Connection using Stream Sockets: The Client 4 steps to building the client: 1. Establish a connection to the server: Socket connection =new Socket(serverIP,port#); A connection is returned if this step is successful, otherwise an IOException is thrown. Notice, the client needs to know where the server is (the server’s IP) while the server doesn’t know in advance the client’s address.

Simple Client continued: Step 2 3. The client gets I/O connections associated with the socket. ObjectInputStream input = new ObjectInputStream(connection.getInputStream()); ObjectOutputStream output = new ObjectOutputStream(connection.getOutputStream()); Other stream types can be used to wrap around these for manipulation different object types. Any serializable object can be passed via the IO connection.

Simple Client continued 3. Processing phase 4. Close the connection by invoking close() method on the streams. This is application specific- the client needs to know when the server is done so as to avoid an IOException (EOFException) trying to read past EOF mark.

server code (in slide notes) ernet programming/Server.htmlhttp://employees.oneonta.edu/higgindm/int ernet programming/Server.html

Client code ernet%20programming/Client.htmlhttp://employees.oneonta.edu/higgindm/int ernet%20programming/Client.html

ServerTest app: erverTest.htmlhttp://employees.oneonta.edu/higgindm/internet%20programming/S erverTest.html import javax.swing.JFrame; public class ServerTest { public static void main( String args[] ) { Server application = new Server(); // create server application.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); application.runServer(); // run server application } // end main } // end class ServerTest

Clienttest.java app feeds a url: g/ClientTest.html g/ClientTest.html import javax.swing.JFrame; public class ClientTest { public static void main( String args[] ) { Client application; // declare client application // if no command line args if ( args.length == 0 ) application = new Client( " " ); // connect to localhost else application = new Client( args[ 0 ] ); // use args to connect application.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); application.runClient(); // run client application } // end main }

Compile and run Compile 4 java files. Run ServerTest, then ClientTest Exercise: modify clienttest code so a url is entered on the command line. Run the client and server on different machines Hint: You can use c:\ipconfig \all to show a machine’s ip, if you can get to the command prompt Loop back URL is

Server window

Client window

Some communication

Client closes connection

Connectionless Client/server communication via datagrams While the connection-based client/server model is similar to the telephone, the datagram model is more like the post office. The message is posted in sequential numbered packets and re-assembled at the target location. Messages may arrive jumbled, or not at all. This example uses the UserDatagramProtocol (UDP) between client and server.

Server structure in datagram communication DatagramSocket socket;//use this datatype … try{ socket= new DatagramSocket(5000);// specify port# …}catch(SocketException se){…} Wait for packets: Byte data[]=new byte[100]; while(true){//forever loop try{ Datagram receivepacket=new DatagramPacket(data,data.length); socket.recieve(receivepacket); … }catch(IOException e){}

Datagram server continued //Send packet to client…also inside try catch for ioexception: Datagram sendpacket=new DatagramPacket(receivepacket.getData(),receivepacket.getLength(),receivepacket.getAddress(),receivepacket.getPort()); socket.send(sendpacket);

Datagram (packet) server The server uses two DatagramPackets – one to send and one to receive packets. This application uses java.net classes: java.net.DatagramPacket and java.net.DatagramSocket DatagramSocket is created in a try block where the server is bound to a port. Processing on the serverside involves an infinite loop waiting for packets. Clients must specify the server port when sending packets. Datagram method receive() blocks until a packet is received then stores the packet info in its Datagram argument. Methods are called to display sender’s IP, port, message length and the message itself.

Packets: 4 files %20programming/PacketServer.htmlhttp://employees.oneonta.edu/higgindm/internet %20programming/PacketServer.html %20programming/PacketClient.htmlhttp://employees.oneonta.edu/higgindm/internet %20programming/PacketClient.html %20programming/PacketServerTest.htmlhttp://employees.oneonta.edu/higgindm/internet %20programming/PacketServerTest.html %20programming/PacketClientTest.htmlhttp://employees.oneonta.edu/higgindm/internet %20programming/PacketClientTest.html

PacketClient frame

PacketServer frame

Threaded client/server Some background –LockSwingUtilities.invokeLater() –Scanner –Executor for threads –Synchronization using Locks

Scanner Scanner is “replacing” StringTokenizer. It is similar, versatile and easy to use. Deitel pg 59 has an example. import java.util.Scanner; … Scanner input=new Scanner(System.in); int x; x=input.nextInt();

SwingUtilities.invokeLater() Having multiple threads manipulate GUI content may not give expected results. Better to have the event-dispatching thread queue requests to display answers, change colors, and so on, and handle them in order. Here is a method to do it: SwingUtilities.invokeLater( new Runnable(){ public void run(){ …thread does stuff to GUI }});

Executor service for running threads Recommended thread construction in jdk1.5 is public class mythread extends Runnable{ public void run(){ //loop or whatever try{ Thread.sleep(sometime); …the rest of it }catch(InterruptedException e){…} } …}

Executor service for running threads Executor Service example Deitel’s text pg 1059 import java.util.concurrent.*; Thread a= new Thread(…);//not recommended //should be RunnableThingy a= new RunnableThingy(); Thread b= new Thread(…);//as above ExecutorService threadEx=Executors.newFixedThreadPool(2); //can run just two threads threadEx.execute(a); threadEx.execute(b); … theadEx.shutdown();

Executor service for running threads Runnables are managed and executed by a class that implements Executor interface. This has one method, (execute). An executor manages a thread pool. Executor assigns each runnable object to a thread in the pool. If there are none it may make a new thread (newCachedThreadPool) or queue the runnable for the next available thread as in the fixed thread pool.

Synchronization using Lock Example in Deitel text pg 1071 This is fairly similar to providing synchronized methods. import java.util.concurrent.locks.*

Synchronization using Lock import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; import java.util.concurrent.locks.Condition; public class SynchronizedBuffer implements Buffer { // Lock to control synchronization with this buffer private Lock accessLock = new ReentrantLock(); // conditions to control reading and writing private Condition canWrite = accessLock.newCondition(); private Condition canRead = accessLock.newCondition(); private int buffer = -1; // shared by producer and consumer threads private boolean occupied = false;

Synchronization using Lock: set public void set( int value ) { accessLock.lock(); // lock this object try { while ( occupied ) { System.out.println( "Producer tries to write." ); displayState( "Buffer full. Producer waits." ); canWrite.await();// wait until buffer is empty } // end while buffer = value; // set new buffer value // producer cannot store new value until consumer retrieves current value occupied = true; displayState( "Producer writes " + buffer ); // signal thread waiting to read from buffer canRead.signal(); } // end try catch ( InterruptedException exception ) { exception.printStackTrace(); } // end catch finally { accessLock.unlock(); // unlock this object } // end finally } // end method set

Synchronization using Lock: get public int get() { int readValue = 0; // initialize value read from buffer accessLock.lock(); // lock this object // output thread information and buffer information, then wait try { // while no data to read, place thread in waiting state while ( !occupied ) { System.out.println( "Consumer tries to read." ); displayState( "Buffer empty. Consumer waits." ); canRead.await(); // wait until buffer is full } // end while // indicate that producer can store another value // because consumer just retrieved buffer value occupied = false; readValue = buffer; // retrieve value from buffer displayState( "Consumer reads " + readValue ); // signal thread waiting for buffer to be empty canWrite.signal(); } // end try // if waiting thread interrupted, print stack trace catch ( InterruptedException exception ) { exception.printStackTrace(); } // end catch finally { accessLock.unlock(); // unlock this object } // end finally return readValue; } // end method get // display current operation and buffer state } // end class SynchronizedBuffer

Threaded client/server code links below and in slide notes cTacToeServerTest.htmlhttp://employees.oneonta.edu/higgindm/internet%20programming/Ti cTacToeServerTest.html cTacToeServer.htmlhttp://employees.oneonta.edu/higgindm/internet%20programming/Ti cTacToeServer.html cTacToeClient.htmlhttp://employees.oneonta.edu/higgindm/internet%20programming/Ti cTacToeClient.html cTacToeClientTest.htmlhttp://employees.oneonta.edu/higgindm/internet%20programming/Ti cTacToeClientTest.html

TicTacToeServer In notes

TicTacToe client

Compile & run Compile the 4 files. Run TicTacToeServerTest first. You need to run 2 clients (players). A window opens for the server and a board appears for each client.

Client boards after play

Exercises Modify the client to connect to a server on another machine. “Fix” the server so it can tell when the game ends.

Socket project Modify the threaded client server to play your choice: Hexapawn on 4X4 or larger board Dominoes Othello A simple card game War, or maybe “21” First option may be easiest. Othello also isn’t too hard. Make sure the server recognizes whose move it is, allows only correct moves, and knows when the game is over (or when a client terminates).