chapter 5 – designempublic.dcs.warwick.ac.uk/.../writeup/word97/chapter5.… · web viewchapter...

Interactive VRML front-end to dtkeden Design

Chapter 5 – DesignThis chapter details the design phase of both the dtkeden interface tools and the

VRML worlds for each of the virtual clients.

Design of the dtkeden interface toolsThe present situation

Figure 5.1 illustrates the present situation of communication between dtkeden clients

and the server. Illustrated with the Clayton Tunnel train crash model, it can be seen

how the six clients communicate with the single server.

Figure 5.1 The current situation of dtkeden.

From looking at the above diagram, methods of interfacing into dtkeden were thought

about, and after being studied for a long time, it was found that instead of interfacing

into dtkeden itself, it would be easier and more useful to interface into the actual

communication taking place. One such example of interfacing directly into dtkeden is

emhttpd, a package created by Ashley Ward that sets up a http server to interface into

dtkeden, allowing interaction through web-pages to a dtkeden model. After

considering the technical complexity, and limited use to this project, a different

approach was sought, one that interfaced directly into the communication. Although

not used in this project, the combination of Ward’s web front-end tool, and the tools

to be produced here, together could be used to further extend both of their individual

functionality.

9


As all communication is carried out through TCP/IP socket based data-stream

communication, it would be conceivable to create an agent that could sit in-between

the client and server, observing all communication taking place.

Snoopy

0


After realising that the above method of interfacing into the communication process

was feasible, the name ‘Snoopy’ was given to this part of the project, as in a way it

would snoop on any communication taking place. Figure 5.2 shows how this would

be achieved.

Figure 5.2 Introduction of Snoopy

Controlled by a main module, Snoopy should insert agents into the communication

process in order to observe and report back any communication taking place,

obviously using the same socket/stream based communication principles as dtkeden.

In order to maintain seamless communication between the clients and server, each

agent will need to be concurrently executed, and hence the process of sending back

details of any communication received by the agents, will need to be concurrent. This

will be achieved by using Java’s concurrency feature, multi-threading.

Detailed below is the process in which Snoopy should carry out the forwarding and

receiving of any communication from the client to the server and vice versa.

Page 21


Instead of specifying the hostname in the invocation of a dtkeden client as the host on

which the dtkeden server resides, the hostname will need to be specified as the host on

which Snoopy is being run on. This parameter, specified by the –h flag, will be the

only parameter that needs to be changed when running a dtkeden model. Lets assume

again that the model will be using channel 55 to run on, remembering that this means

that all communication will be carried out via port 9055.

When a dtkeden client connects to port 9055 on the host Snoopy runs on, Snoopy

should able to ascertain enough information from this connection request, and

previously know information about the location of the server, to link that client and

the server together. From the connection request, the socket, which the client is using

on their host system, can be found and a stream opened up between the two sockets of

the client and Snoopy. From the opening of this stream, the writing of data to the

client and the reading of the data from the client is enabled. Knowing which dtkeden

channel number is be used, Snoopy should be able to connect to the dtkeden server,

again opening a stream to link the two. This second stream should give the remaining

two channels of communication necessary to complete the link between client and

server, the writing of data to the server, and the reading of data from the server.

Knowing these, the Forwarder and Receiver threads can be initialised:

FromClient FromServerForwarder Receiver

ToServer ToClient

To enable seamless running of both the Forwarder and the Receiver, when any data is

received by either, a new thread would be started up to handle the sending of the

details of the communication back to Snoopy. Whilst sending information to Snoopy,

the Forwarder thread should also look for the line @#$%EOU%$#@<client-name>,

as from this line the Forwarder and Receiver can learn the name of the client they are

serving. This information should be used to accompany any details sent back to

Snoopy, along with a time-stamp. These details should be in the standard form of a

protomessage. (See later.)

Page 22


Operating in this mode, Snoopy appears to be very much a standalone tool. In fact

this is correct, and is one of the two such ways in which Snoopy should be able to

operate. In the second mode of operation, Snoopy should be able to receive standard

protomessages from an external Communicator tool (described later), and pass them

on to the relevant Forwarder / Receiver to ensure that the message reaches its

destination. Running in this mode, Communication mode, Snoopy should allow full

interaction with any client or the server, running in the former mode, Standalone

mode, Snoopy provides invaluable information for purposes such as debugging.

The Protomessage

Throughout the whole set of tools, a standard will be required for the content and

structure of any messages sent. After careful deliberation on the type of messages, the

most straightforward and easily implementable structure found was:

<to-name>%%<from-name>%$message

Where the to-name indicates where the message was/is intended for, the from-name

indicates where the message was sent from and the message part containing the

information/data being sent. For example:

Killick1%%god%$startTime = 981567248;

Would be intended for Killick1 and was sent by god, sending the information of

“startTime = 98156727;”. (Example taken from the Clayton Tunnel model.)

God%%Killick2%$flagShowing = true;

Would be intended for god, from Killick2, with message “flagShowing = true”.

With the protomessage in this form it is easy to break down into its individual

components whenever necessary, also being easy, quick and uncomplicated to

construct or interpret when viewed by a user.

The Web Server

Page 23


For security reasons, in order for Java Applets to connect to a server, they must be

served from that same server. As the VRML used in this project contains Java code

that connects to a server, running the VRML through an Internet browser means that

the Java code inherits the same security constraints as an Applet. This constraint

means that in addition to the other tools produced, a webserver would have to be

included among the tools to make them a much more integral unit, and hence more

usable in a wider range of situations. Figure 2.3 shows the inclusion of the webserver

module into the overall set of tools designed so far.

Figure 5.3 Inclusion of the webserver

Indicated on the right of the diagram are the virtual clients that will be used to display

the VRML, and interact with the existing Clayton Tunnel model clients indicated on

the right hand side of the diagram. Also being controlled by the same module as

Snoopy, this allows just one module to be started up aiding ease of use of the

completed set of tools.

The webserver should work by listening on a given port number on the host machine

that it is running on. When a HTTP request is made to the webserver through this

Page 24


port, the webserver should handle this request concurrently by starting up a new

thread to serve the request. Initialised with a port number to serve on, and a directory

location to serve files from, the webserver listens for requests. The flow diagram in

Figure 5.4 below shows how the execution of such a request should be handled:

Figure 5.4 Flow diagram showing the operating of the webserver

Below is an annotation of Figure 5.4, showing in detail each of the individual steps.

1. The webserver receives the request.

2. An output stream should be opened back to the client so that the requested

file/page, or details of any errors occurring during the serving of the request can

be sent back to the client requesting it.

Page 25


3. The request should be checked to ensure that the request starts with a GET, as this

should be the only form of HTTP request that this webserver need be able to

handle.

4. If a GET request was made, the structure of the file path should be examined.

5. If something other than a GET request was made, an error code 501 (feature not

implemented) should be returned to the user to inform them that this webserver

only handles GET statements.

6. After the error code 501 details have been sent to the user, the request is finished

so the output stream should be closed.

7. Following on from 4, the file path should be checked to see if it ends in a /

symbol.

8. If the file path does end in a /, then index.html should be appended onto the path.

9. The next thing that the webserver must do is open the file so that it can read the

contents and output them down the output stream to the requesting client.

10. If the file is not found, then an error code 404, file not found should output to the

client.

11. After this, the output stream should be closed.

12. If the file is found, but access to that particular file is not allowed, an error code

404, access denied should be output to the client.

13. After this, again, the output stream should be closed.

14. If there are no problems in opening the file for reading, then the contents should

be output through the output stream to the client.

15. On successful completion of the request, the output stream should be closed.

The design for this webserver was created bearing in mind that it only needed to be as

simple as possible to work effectively enough to do the job. Background reading for

the requirements of a webserver came from a book on Computer Networks [6]

The Communicator

Page 26


The communicator is the final missing piece of the jigsaw puzzle, enabling

communication between any virtual clients created and the actual dtkeden clients.

Figure 5.5 below shows the inclusion of the communicator into the set of tools, and

the role that it plays.

Figure 5.5 The completed set of tools

Logging itself into Snoopy, the Communicator should put Snoopy into

Communication mode, where as described earlier, any protomessages that Snoopy

receives should be passed on through to the Communicator, which should handle

them, passing on any relevant information to the relevant virtual client.

In order for the Communicator to know which virtual clients require which

protomessages to be passed onto them, the Communicator should store a list of

Oracles for each virtual client. These Oracles, as in dtkeden, should define what

information the client wishes to receive, hence if one of the Oracles for

VirtualKillick1 was defined as signalSign, then receiving any protomessage

containing the signalSign variable would be passed onto VirtualKillick1. Each time a

protomessage is sent from Snoopy to the Communicator, it should inspect the

Page 27


message part of the protomessage and retrieve the variable concerned. It should then

look through the oracles for each virtual client, and decide which to send the message

part of the protomessage to.

In order for the Communicator to be concurrent in its handling of all virtual clients, a

separate ClientCommunicator should be created every time a new virtual clients logs

into the Communicator. When logging in, the first piece of information that the

ClientCommunicator should receive from the virtual client is its name, followed by its

Oracle definitions. Once again, in order for the running of all communication

between the virtual clients and dtkeden clients to be concurrent, a new ClientSender

should be started up each time a message is to be sent from a virtual client through the

Communicator and Snoopy to a dtkeden client (or server).

Design of the VRML Worlds

Throughout the design process of the VRML clients, the term World is used to

indicate each client’s particular view on the whole world. For example, because

Brown will not be able to see Killick, the section of the whole world that Brown can

see will be termed Brown’s World, whereas God should be able to see everything, this

being termed God’s World.

Scene graphs

One way of representing VRML files is to produce a scene graph, which in essence is

a tree like graph describing each of the individual parts of a VRML file, called Nodes.

Upon deciding the contents of the VRML file, a scene graph can be drawn up to be

followed during implementation. Figure 5.6 shows the standard way of representing

scene graph nodes, found in most good VRML books, along with Figure 5.7

demonstrating a simple example.

Page 28


Figure 5.6 Standard representations of scene graph nodes.

Figure 5.7 Example of a scene graphBrown’s World

Page 29


The photos that were taken of the entrance to the Clayton Tunnel during the visit to

Pyecombe were of the North end of the tunnel, the end at which signalman Brown

was working. The first job was to work out from the photos the basic parts that would

be required in Brown’s world in order to make the scenery look realistic, but not too

complicated. To do this, a rough sketch was made of how Brown’s world should

look. Figure 5.8 shows this below:

Figure 5.8 The initial sketch of Brown’s world

From this drawing, the list of parts required to make this world could be worked out in

order to produce a scene graph. They are as follows:

The standard way of heading a VRML file, world info, navigation info,

viewpoints and setting the background.

The Tunnel Entrance portal, complete with cottage in-between the towers.

Two grass embankments, either side of the track.

A bridge over the track to represent the road bridge.

Page 30


A large shape of earth behind the portal to give the impression of a hillside.

Some trees behind the portal

The tunnel itself running through the hill behind the portal

A signalman’s signal box.

An area to represent the earth that the two rail tracks stand on.

The two railway tracks.

Three trains.

The script to control the three trains, utilising the tools designed earlier.

A light in the world to represent sunlight.

Initially, scene graphs were not produced for each of the individual components of the

world, but were produced during the implementation phase, and is detailed in that

chapter. (For the full set of scene graphs, including the scene graph for the above

world, please see Appendix E)

Killick’s World

Because this end of the tunnel was a 1.5 mile hike across muddy pastures and dense

woodland, photographs of this end of the tunnel were not taken, although interviews

with local people seemed to build up a vague picture of the area. It is this vague

picture that was immediately draw up on return from Pyecombe, and is shown in

Figure 5.9 below. This end of the tunnel was the location of the train crash back in

1861, and hence will have most of the action. It is for this reason that this area is kept

as simple as possible, in order to get a quicker, more realistic frame rate from the

VRML.

Killick’s World is conceptually the same as Brown’s world, but with a few minor

changes. These are:

The portal should be replaced by a standard ‘brick effect’ tunnel entrance.

The addition of a few extra trees.

The addition of a signal post and arm, controlled by the Script node for the trains.

Page 31


The steepness of the embankments should be decreased.

The addition of a flag that can be made visible to a passing train.

Figure 5.9 The initial sketch of Killick’s World

Once again, the individual scene graphs were not produced until the implementation

phase. From the above drawings and the scene graphs produced, the necessary

visualisation was complete in order to implement the VRML worlds at both ends of

the tunnel.

God’s World

God’s world should be just both Brown’s world, and Killick’s world connected

together by a tunnel. The connecting tunnel, for the purposes of visualising the trains’

movement through the world should be transparent. As God’s World is just the

composition of the two worlds, scene graphs were deemed unnecessary and hence not

produced.

Drivers Worlds

Page 32


The VRML worlds for each of the 3 drivers is exactly the same as God’s world, with

only one train, and the viewpoint fixed within the cockpit of this train. Once again, no

scene graphs were produced for these three worlds.

The Still World

In order to demonstrate the VRML freely, away from the interaction with dtkeden, a

Still World should be created – with no Java, and hence no connections to the dtkeden

model. In this world the VRML is exactly the same as God’s World, minus the Script

node for controlling the signal and trains, which should be statically placed along the

train lines at key positions.

Design of the Java Clients

In order for the VRML to be effective enough in visualising the train crash, the

control over the individual elements in the world, i.e. Signal arm position, train

throttle position etc. will need to placed outside of the VRML world. Instead of being

within the VRML world, these controls should be placed in Java Applets surrounding

the VRML browser plug-in window.

For signalman Killick, the controls that should to be provided should be:

A Signal arm position indicator, along with buttons to raise and lower the signal

arm manually.

An alarm, and a reset switch.

A telegraph needle, with the standard three positions, ‘Train in tunnel’, ‘Neutral’

and ‘Clear’ and the ability to operate the needle.

Three flags that can be used to wave a flag in the VRML world, to indicated a Red

flag, a White flag and no flag.

Page 33


For signalman Brown, only one control is necessary, a telegraph needle of the same

type. Figures 5.10 and 5.11 below show the initial sketches of the two web page

windows that should contain the VRML and Java Applets of the two signalmen.

Figure 5.10 The initial design for the Killick client

Page 34


Figure 5.11 The initial design for the Brown client

The remaining VRML clients are the Drivers. As with the Killick and Brown client,

all functionality should be placed into surrounding Java Applets to allow the VRML

to be used purely as a visualisation tool. The controls that need to be provided by the

surrounding Java Applets for each driver should be:

A speedometer to indicate the present speed of the train.

A throttle on a continuos slider from BRAKE, to ACCEL.

A gear level, allowing the train to be put in either forward or reverse gear.

A position indicator, purely for the purposes of easing the visualisation process.

Page 35


Again, an initial drawing of a driver client is shown below in Figure 5.12.

Figure 5.12 The initial design of a driver Client.

Because God’s world and the Still world should have no interactivity, there is no need

for Java clients to be designed for them.

Page 36


Page 37

chapter 5 – designempublic.dcs.warwick.ac.uk/.../writeup/word97/chapter5.… · web viewchapter...

Documents