software engineering 3156 3-oct-01 #8: specification phil gross
Post on 22-Dec-2015
222 views
TRANSCRIPT
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
3
More Stuff?
Heartbeats?– Ping and Pong messages
Better logon mechanism?– Confirm password
Compressed map format? Need your feedback
4
Extensions
Find other interested groups, if necessary Talk to us Go for it Example: floating-point location instead of tile
5
Specification Details
We incorporated your suggestions More details More iterations needed – give us feedback
6
Requirements Doc
Partially revised Requirements-style 30,000-foot-view Use
Cases
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…
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
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
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
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
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
13
Game Entry/Exit
Enter/Quit game– Client requests
KickGame– Server boots you
ExplicitSave– Client requests that current actor state be sent to
repository
14
Editor
Get data from Editor mode of client to server SendObject, LoadMap
– Plus confirmations
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
16
Exceptions
ExMoveForbidden, ExNoConversation, ExKicked, ExNoPermession, ExUnknown
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)
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
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
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
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
22
Examples
Partial More coming Give us your requests/questions
23
Service Discovery
DNS– SRV records– SIP
X.500 / LDAP Jini Berkeley SDS SLP Wireless
24
Service Discovery
DNS– New: SRV records
X.500 / LDAP Jini SIP Berkeley SDS SLP Wireless
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
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)
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
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
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
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…
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
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)
33
LDAP Map 2: Actors
ActorRef (userID) ImageURL HP:int XP:int Gold:int Encrypted password Only game server can read/write
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