1 / 34

Software Engineering 3156

Software Engineering 3156. 3-Oct-01 #8: Specification Phil Gross. Administrivia. About asymmetric groups http://groups.yahoo.com Homework submission General questions to webboard. More Stuff?. Heartbeats? Ping and Pong messages Better logon mechanism? Confirm password

dante
Download Presentation

Software Engineering 3156

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. Software Engineering 3156 3-Oct-01 #8: Specification Phil Gross

  2. Administrivia • About asymmetric groups • http://groups.yahoo.com • Homework submission • General questions to webboard 2

  3. More Stuff? • Heartbeats? • Ping and Pong messages • Better logon mechanism? • Confirm password • Compressed map format? • Need your feedback 3

  4. Extensions • Find other interested groups, if necessary • Talk to us • Go for it • Example: floating-point location instead of tile 4

  5. Specification Details • We incorporated your suggestions • More details • More iterations needed – give us feedback 5

  6. Requirements Doc • Partially revised • Requirements-style 30,000-foot-view Use Cases 6

  7. Changes to Schema • Call it version 0.9 • Fewer messages • Delta has object-change info • Instances can have different image URLs • Talking vs. attacking • We have some sample messages • More… 7

  8. All Objects… • Have a unique ID • Have a default URL where the image representation can be found • Client can cache images, or request all from server on startup 8

  9. All Components… • Talk to LDAP • Java JNDI interface; We’ll be giving you code • Talk XML • I gave you sample JDOM code • Talk over the network • We showed you basic networking code • Will be multithreaded • We’ll be talking about that at design time 9

  10. The GameEvent Element • A message between components • AIs and clients request moves • Server evaluates them and sends deltas out to all connected clients/AIs 10

  11. Move And Chat • Movement requests • Checked for validity and timing, and either granted or rejected • Start/EndChat • Enter conversation mode • Send/ReceivedText • Exchange chat messages 11

  12. Attacks And Change • Attacked • Gives result of an assault • Gone: • ReplaceObject • Bot with a corpse, closed chest with open chest, etc. • ChangeStats • Flip a status bit, give health, hp, xp, gold, etc. • StatusMessage • Get a message from the server 12

  13. Game Entry/Exit • Enter/Quit game • Client requests • KickGame • Server boots you • ExplicitSave • Client requests that current actor state be sent to repository 13

  14. Editor • Get data from Editor mode of client to server • SendObject, LoadMap • Plus confirmations 14

  15. Data Transfer • MapData • The absolute info • GetAllInstances • Responds with AllInstances • All Items, Actors, and Bots • MapDelta • Changes since last delta • Deltas have a sequence number for detection of dropped events 15

  16. Exceptions • ExMoveForbidden, ExNoConversation, ExKicked, ExNoPermession, ExUnknown 16

  17. GameMap Element • Contains all the information necessary to describe a game map, including graphics for the client and simple scripts for the AI • Basic entities: • Tiles • Objects • Bots • Actors (user players) 17

  18. Map Element Parts • Metadata – basic info on map • {tile | item | bot}set • For tile and item, unique ID plus URL to graphic • For bot, initial state plus scripts • More on scripts later • {tile | item | bot | actor}instances • An instance of a class at a particular location on the board and with its own instance data • Item instances have behaviors 18

  19. Actors • Bots are an extension of this • Have hp, xp, name, speed attribute • And a status word • 32 bit value • Each bit represents some accomplishment in the game • Interactions with objects and bots can set bits • Setting bit 31 ends game • Covers both inventory and plot progression 19

  20. Bots • Have a state, and sometimes a target, plus possibly a master • State: current activity, e.g. attacking, fleeing, wandering, conversing, assisting • State says what to do, but it’s up to the AI to actually do it • Target: for certain states, e.g. attacking • Master: If assisting, this is the character to assist 20

  21. Bot Scripts • For a given state, describe what to do if someone is seen, conversed with, or interacted with • Filter: check any of my and their instance variables • Result: if filter passed, these effects happen • OtherFilter applied to all other “visible” entities, plus target 21

  22. Examples • Partial • More coming • Give us your requests/questions 22

  23. Service Discovery • DNS • SRV records • SIP • X.500 / LDAP • Jini • Berkeley SDS • SLP • Wireless 23

  24. Service Discovery • DNS • New: SRV records • X.500 / LDAP • Jini • SIP • Berkeley SDS • SLP • Wireless 24

  25. DNS: Domain Name Service • Primary purpose: “discover” machines • “Address record”: for example, www.cs.columbia.edu = 128.59.16.149 • Equivalent to an address book • Secondary purpose: advertise mail servers • “Mail server”, or MX record: cs.columbia.edu’s mail is primarily handled by ober.cs.columbia.edu 25

  26. DNS (II) • More recent: user-definable services, using SRV records • Domain controllers • Telephony servers • Generally done on a domain basis: “here’s the service provider for domain X” • Tools for DNS • nslookup • host • numerous API’s (resolver built into Java sockets) 26

  27. Others (I) • SIP: Session Initiation Protocol: Invented Here! • http://www.cs.columbia.edu/~hgs/sip • Basic idea: how to find someone to communicate with • Primarily for telephony applications (Caller-ID, Call-Forwarding, etc.) • Jini: distributed object-level service discovery • Appliance-aware services: embedded Java 27

  28. Others (II) • Berkeley SDS: current research • Improve security and scalability of service discovery mechanisms • SLP (Service Location Protocol) • IETF attempt, generalized SIP, less successful • NIS (Network Information Service) • Primarily user authentication, but can generalize • “Mirror” /etc files 28

  29. Challenges for service discovery • Running out of IP addresses on which to host these services • IPv6 • Lack of a standardized mechanism • Each service discovery mechanism has its own target applications • Mobile services • Wireless technology: “find” the service physically 29

  30. LDAP: Lightweight Directory Access Protocol • One popular solution to general discovery requirements • Very generalized white-pages mechanism • User-definable “schemas” • Common applications are network nodes and users • Based on DAP, X.500 • Extremely popular • ldap.columbia.edu: try it out… 30

  31. LDAP (II) • We will be using LDAP for several purposes • Discovering server and AI programs on the network • Keeping track of basic user authentication and information • LDAP server already set up on softe.cs.columbia.edu • Code examples will be covered in next week’s recitation • Don’t need the code for specification document 31

  32. LDAP Map 1: Servers • Mapref • Title • IP • Port:int • ExtensionList • ServerType:char (0=Game, 1=AI) • All can read, only servers can write (at startup) 32

  33. LDAP Map 2: Actors • ActorRef (userID) • ImageURL • HP:int • XP:int • Gold:int • Encrypted password • Only game server can read/write 33

  34. LDAP Map 3: Actor → World • ActorRef • WorldRef • LocationX:int • LocationY:int • Status:long • WorldInstance:long • Timestamp from when server was started • Read/Write by server at player entrance/exit 34

More Related