multi-platform, multi-os client/server Suppose we send data between clients and servers… Architectural issues impact client/server code Little-endian/Big-endian issues • 0xabcd is a 32-bit value, which is MSB? How is this stored? How big is an int? 32-bits, 64 bits, … Towards raising the level of discussion Worrying about integer byte order is not fun Let’s worry about sending objects back-and-forth, not bytes How do we send and receive objects? 5.1 Software Design
Client/Server Communication The Java stream hierarchy is a rich source of options Object streams, Data streams, Buffered Readers, … Often these convert between bytes and characters • What’s the story with Unicode? (e.g. compared to ASCII) • FileStream, BufferedReader, …, We can read and write objects over sockets Advantages compared to lower-level protocols? Disadvantages? Issues in understanding and implementing Where do objects “live”, are classes different? Subclass/Superclass issues What about connection issues (where, how, knowledge) 5.2 Software Design
Clients and Servers: server side Server socket exists on some machine, listens to a “port” A port isn’t a physical concept, it’s an OS concept The OS manages ports, some services listen at predetermined ports, e.g., mail at port 25 • User programs use ports above 1024 Server gets a connection and handles the request, but what about other connection requests? Can’t be too busy processing request, or will miss other attempts at connections Spin off handler as a separate program/process Server blocks on accepting connections, new jdk1.4 API for java.nio.channels might improve things Why is blocking not ideal? 5.3 Software Design
Networked Games What will go over the network? Board? Move? Other? Where is the controller? Server? Client? Combination? How does the server work for many games? Rules important? 5.4 Software Design
Simple Client/Server code The example shows how a client communicates commands to server Deciding how to process a command is simple, but not robust/OO in the current model How are client and server similar? Different? Both know about all commands? How do they know this? 5.5 Software Design
Architectural considerations What can we do to generalize things, move away from chain of if/else code Create commands corresponding to protocol Execute command obtained by map What’s in the map? Some commands require state, e.g., more data from server or client Can have a map of string to object, but how to get information into the object? Can map string to object factory, have a per-command factory Factory knows how to create each command 5.6 Software Design
Networked games: ooga to nooga Different games make writing general server difficult Turn based games… Multiplayer asynchronous games like Boggle… Noah’s Ark, Samegame, … Nooga story at Duke Each summer for the past N summers … • Do we have a general, usable architecture? What should we do next? What are key issues in developing networked games Don’t worry about robustness or generality 5.7 Software Design
From controller to threads Threads are lightweight processes (what’s a process?) Threads are part of a single program, share state of the program (memory, resources, etc.) Several threads can run “at the same time” • What does this mean? Every Swing/AWT program has at least two threads • AWT/event thread • Main program thread Coordinating threads is complicated Deadlock, starvation/fairness Monitors for lock/single thread access 5.8 Software Design
Concurrent Programming Typically must have method for ensuring atomic access to objects If different threads can read and write the same object then there is potential for problems • ThreadTrouble.java example • Consider getting x and y coordinates of a moving object If an object is read-only, there are no issues in concurrent programming • String is immutable in Java, other classes can have instance variables be defined as final, cannot change (like const) In Java, the keyword synchronized is the locking mechanism used to ensure atomicity Uses per-object monitor (C.A.R. Hoare), processes wait to get the monitor, it’s re-entrant 5.9 Software Design
Using synchronized methods Methods can be synchronized, an object can be the argument of a synchronized block, a class cannot be synchronized Every object has a lock, entering a synchronized method of the object, or using the object in a synchronized block, blocks other threads from using synchronized methods of the object (since the object is locked) If a synchronized method calls another synchronized method on the same object, the lock is maintained (even recursively) Another thread can execute any unsynchronized method of an object O, even if O’s lock is held A thread blocks if it tries to execute a synchronized method of an object O if O’s lock is held by a different thread 5.10 Software Design
Thread classes in Java Classes can extend java.lang.Thread or implement java.lang.Runnable , (note: Thread implements Runnable) A thread’s run method is executed when the thread is started Typically the run method is “infinite” • Executes until some final/done state is reached • The run method must call sleep(..) or yield(); if not the thread is selfish and once running may never stop A runnable object is run by constructing a Thread object from the runnable and starting the thread Threads have priorities and groups Higher priority threads execute first Thread groups can be a useful organizational tool 5.11 Software Design
Recommend
More recommend
