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.
Page 19
Interactive VRML front-end to dtkeden Design
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
Page 20
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
Figure 5.6 Standard representations of scene graph nodes.
Figure 5.7 Example of a scene graphBrown’s World
Page 29
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
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
Interactive VRML front-end to dtkeden Design
Page 37
Recommended