1 / 27

Flight Simulation Client/Server

Flight Simulation Client/Server. Malcolm Mumme. Introduction. Using Java features to program Client/Server applications Threads, Sockets, inheritance, &c. (all page number references are to the textbook). Topics of Discussion. Java Threads and Strand Threads

Download Presentation

Flight Simulation Client/Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Flight Simulation Client/Server Malcolm Mumme

  2. Introduction • Using Java features to program Client/Server applications • Threads, Sockets, inheritance, &c. • (all page number references are to the textbook)

  3. Topics of Discussion • Java Threads and Strand Threads • Socket input buffering with ReEnumerator • Simulation state updates with Entity and SimMonitorMessage • Output Synchronization • Managing clients in SimEngine • Display updates using SimulationClient and Radar/WinDisplay

  4. Java Threads and Strand Threads • Text implies that Threads may outlive the objects that contain them. (p. 842) • This is not consistent with the usual approach to objects • Define Strand class as a more OO Thread • Strand interface similar to Thread: • new Strand( (Runnable)this ); • Strand will automatically start the thread at construction and stop the thread upon finalization (p. 472)

  5. Java Threads and Strand Threads • A class’s finalizers can be overriden by subclasses, parent finalizers are not automaticaly called as with constructors(p. 516) • Avoid this problem by using a helper final class StrandThreadContainer who’s finalize() method stop()s the Thread.

  6. Socket input buffering with ReEnumerator • Why Socket input buffering? • A multi-user server must not be forced to wait on an individual Socket • An Enumeration(p. 769) is a convenient way to package a sequence of messages • A ReEnumerator packages a sequence of Enumerations

  7. Socket input buffering with ReEnumerator A Server • A multi-user server must not be forced to wait on an individual Socket Client1 in in Stream Socket Socket out out Stream Client2 in in Socket Socket out out

  8. Socket input buffering with ReEnumerator A Server • A multi-user server must not be forced to wait on an individual Socket Client1 in in Stream Socket Socket out out Stream Client2 in in Socket Socket out out

  9. Socket input buffering with ReEnumerator an Object An Enumeration • An Enumeration(p. 769) is a convenient way to package a sequence of messages nextElement() an Object an Object hasMoreElements() an boolean

  10. Socket input buffering with ReEnumerator • A ReEnumerator contains a Strand Thread which keeps the main thread from having to wait on a Stream • nextElement() returns an Enumeration • That Enumeration supplies those messages that have already been buffered. • MessageEnumeration is an extended Enumeration interface for this program that has a method nextSimMonitorMessage()

  11. Socket input buffering with ReEnumerator an Enumeration A ReEnumerator buffer • A ReEnumerator packages a sequence of Enumerations nextElement() an Enumeration an Enumeration buffering Strand a boolean hasMoreElements()

  12. Socket input buffering with ReEnumerator • A MessageEnumerator wraps(p. 725) an input Stream with a MessageEnumeration • MessageReEnumerator is a special ReEnumerator that works with a MessageEnumeration • …= new MessageReEnumerator( new MessageEnumerator( in ) ) wraps and buffers the stream

  13. Simulation state updates with Entity and SimMonitorMessage • Each simulated thing has a corresponding Entity Object in the SimEngine • Each Entity contains several simulation parameters relating to it( position, velocity, orientation, shape, color, name,spin rate &c. ) • An Entity can step() itself forward in time to do it’s part of the simulation

  14. Simulation state updates with Entity and SimMonitorMessage • A SimMonitorMessage communicates partial update information about an Entity and can update(Entity) • There is a subclass of SimMonitorMessage for each parameter in an Entity • A SimMonitorMessage can be read from a DataInputStream and can update an Entity • A SimMonitorMessage can be constructed from an Entity and can write itself to a DataOutputStream …

  15. Output Synchronization • A SimMonitorMessage writes itself to a DataOutputStream in many little pieces. • There is more that one Strand(Thread) in the SimulationServer in which this may occurr. • This must always be done with “synchronized” methods(p. 851) : • public synchronized static void sendAllMessages( … ) • public synchronized static void sendUserControlMessages(…) • …

  16. Output Synchronization In Thread A, SimMonitorMessage X writes itself to out OutputDataStream out • … in many little pieces. …There is more that one Strand … in which this may occurr. In Thread B, SimMonitorMessage Y writes itself to out X0 X1 X2Y0X3Y1X4 X5 …

  17. Managing clients in SimEngine • The SimEngine starts running a simulation Strand at construction • The SimulationServer Object adds clients to the SimEngine by invoking the addMember(Socket) method • Clients may leave at any time on request or by just aborting and causing an IOException on a Socket • The SimulationServer may destroy the SimEngine at any time in response to the “Quit” button

  18. Managing clients in SimEngine • When the SimulationServer Object adds clients to the SimEngine by invoking the addMember(Socket) method, • A new simulation Entity corresponding to the client must be created and initialized • All existing clients must be updated adding the new Entity • The new client must be informed of it’s corresponding Entity • The new client must be downloaded with the entire simulation state

  19. Managing clients in SimEngine • A client may quit at any time. • The SimEngine may be informed of this by: • 1: a request from the client • 2: an IOException on that clients Socket • The corresponding Entity must be removed, and all remaining clients must be then informed of that. • When the client requests to quit, the SimEngine also informs the same client (as well as all the remaining clients) of it’s Entity being removed

  20. Managing clients in SimEngine • The SimulationServer may destroy the SimEngine at any time in response to the “Quit” button A client may quit at any time. • The SimEngine has a finalize() method which does the following: • Each Entity must be removed and each corresponding client must be then informed of that.

  21. Display updates using SimulationClient and Radar/WinDisplay • A SimulationClient connects to the SimulationServer with a Socket in the usual way(p. 862) • The simulation state is duplicated on each client using the same class Entity used on the server • The SimMonitorMessage class is used for all messages both from and to the SimulationClient

  22. Display updates using SimulationClient and Radar/WinDisplay • A SimulationClient must receive all messages from the SimulationServer • It must create an Entity Object when informed of it’s existence • It must update the corresponding Entity when it receives a SimMonitorMessage from the SimulationServer • It must remove an Entity for which it receives a “Quit” message

  23. Display updates using SimulationClient and Radar/WinDisplay • A SimulationClient must remember to which Entity it corresponds • It must render visual images from the point of view of it’s corresponding Entity • It must update it’s Entity and the SimulationServer whenever the user changes a control on the Applet Window • It must quit when it’s Entity is removed by the SimulationServer

  24. Display updates using SimulationClient and Radar/WinDisplay • A SimulationClient display images are rendered in the WinDisplay Applet that maintains the primary display area(by means of the renderAll() method). • Within renderAll ,a polygonal model is extracted from each Entity • The light on each polygon is adjusted according to it’s orientation. • Each polygonal model is geometricaly manipulated to it’s relative orientation and location as it should appear on the display.

  25. Display updates using SimulationClient and Radar/WinDisplay • A shadow polygon at altitude 0 is created in some cases. • Each polygonal model is clipped to remove parts that would not be visible within the display window • After all polygonal models are geometricaly processed, they are reordered to approximate a visibility algorithm. • All polygons are then rendered to a clean Image using the fillPolygon method, which is then copied to the window by drawImage to minimize flicker.

  26. Potential improvements • Add a dialog to the client for obtaining the Server host name • Get some better scenery • Correct the visibility algorithm • Add realistic flight dynamics • Improve the appearance of planes • …

  27. What This Means • With Sockets and Threads, you can do fun stuff

More Related