Remote Web Desk

CONTENTS
CHAPTERS PAGE NO
ACKNOWLEDGEMENT i
ABSTRACT ii
LIST OF FIGURES iii
1. INTRODUCTION
1.1 OBJECTIVE 1
1.2 PROBLEM IN EXISTING SYSTEM 1
1.3 SOLUTION OF THESE PROBLEMS 1
1.4 HARDWARE & SOFTWARE SPECIFICATIONS 2
2. PROJECT ANALYSIS
2.1 STUDY OF THE SYSTEM 3
2.2 NEED FOR COMPUTERIZATION 3
2.3 MODULES 4
2.4 PROJECT FEATURES 4
3. TECHNOLOGIES
3.1 JAVA 5
3.2 NETWORKING 7
3.3 REMOTE FRAME BUFFER 8
4. PROJECT DESIGN
4.1 UML DIAGRAMS 17
4.2 DATA FLOW DIAGRAMS 28
4.3 SOFTWARE FLOW DIAGRAMS 33
5. ARCHITECTURE 35
6. PROJECT TESTING
6.1 INTRODUCTION OF TESTING 38
6.2 TESTING OBJECTIVES
6.3 TYPES OF TESTING 38
7. OUTPUT SCREENS 41
8. CONCLUSION 50
9. BIBLOGRAPHY 51

1
1.INTRODUCTION
1.1. OBJECTIVE
The project Remote Web Desk deals with remote control of computer over some
form of network usually a LAN or the Internet. It allows friend or an administrator to fix
problem on your computer or you can use it to show your desk top to somebody at a
remote location.
1.2.PROBLEMS IN EXISTING SYSTEM
In the present scenario of distributing information using a client-server
environment Telnet is being implemented for communication with a remote login
user.
 There are no graphics in Telnet.
 These are only character based in nature and do not provide an
easy way for “communication across network”.
 The communication is not platform independent
1.3. SOLUTION OF THESE PROBLEMS
The RFB protocol is based around a single graphics primitive: “put a rectangle
of pixel data at a given x, y position”. The RFB relies on sending encoded pixels to
the client that contains the information of the server desktop. The client then decodes
the pixels and draws them on a graphical application running on its machine. Events
occurring at the client side are trapped and send to the server where the changes are
reflected. For this purpose the RFB protocol suggest the use of a frame buffer.
The Frame Buffer actually contains the desktop information, which is updated
when the client generates an event. This updated buffer must send to the server, which
updates its own desktop accordingly. Similarly when the server generates event that
affect the desktop, the updated buffer is redrawn at the client. This provides a
synchronized desktop sharing facility.

2
1.4. HARDWARE & SOFTWARE SPECIFICATIONS
1.4.1 Software Requirement Specification
Language : Java, Applets, AWT, Networking,RFB protocol
Version : JDK 1.5
Operating System : Windows XP
1.4.2 Hardware Requirement Specification
Processor : Intel P-III based system
Processor Speed : 250 MHz
RAM : 64MB
Hard Disk : 2GB to 30GB
Key Board : 104 keys

3
2.PROJECT ANALYSIS
2.1. STUDY OF THE SYSTEM
Remote web desk consists mainly of “Remote Frame Buffer” protocol which
is implemented by a server on the controlled host and a client on controlling host.
Since it makes no assumptions About the content of frame buffer, it is highly portable
and very light weight, being applicable even to embedded systems.RFB provides
facilities to transfer the screen image (or frame buffers) rectangles and transfer these
rectangles containing pixel values to remote user allowing the available participants to
share the view and control of session simultaneously. On the other hand, it also
accepts the user interaction events (e.g. key press, mouse button click etc) from real-
time conferees and forwards the events to the remote session.
The distributed users can access the remote session with heterogeneous
windowing systems such as X11, Windows9x / NT and Macintosh.RFB protocol
enables remote users to share the desktop of the server either exclusively or on a
sharing basis. RFB is a simple protocol for remote access to GUI.Because it works at
a frame buffer level it is applicable to all windowing systems such as X11,
Windows9x / NT and Macintosh. The remote end The remote endpoint where the user
sits (i.e. the display plus keyboard and/or pointer) is called web pad. The endpoint
where changes to the frame buffer originate (i.e. the windowing system and
applications) is known as the RFB server. Web pad truly a “thin client” protocol. The
emphasis in the design of the RFB protocol is to make very few requirements of the
client. In this way, client can run on the widest range of hardware, and task of
implementing a client is made as simple as possible.
. 2.2.NEED FOR DEVELOPMENT
We need a protocol that can well support GUI based client-server interaction and
allow multiple clients to share the desktop of the server

4
2.3. MODULES
 Client
 Server
Client:- The remote end point where the user sits that is the display plus keyboard and/or
pointer.
Server:- The end point where changes to the frame buffer originates (i.e. windowing
system and applications).
2.4 . PROJECT FEATURES
The features that can be implemented are:
 To provide the most robust solution.
 Share the view and control of the server desktop.
 Low total cost of ownership.
 Zero administration.
 Independent of hardware platform, operating system, windowing system.
 RFB client should be adaptive to its computing environment

5
3.TECHNOLOGIES
3.1. JAVA OVERVIEW :
James and others conceived java in 1981.the original impetus for java was not
the Internet! Instead, the primary motivation was the need for a platform-independent
that could create software to be embedded in various devices. Java in an object
oriented and multithreaded programming language. Java derives much of its
characters from C and C++. This is by intent. The java designers knew that using the
familiar syntax of C and echoing the object-oriented features of C++ would make
their language appealing to the legions of experienced C/C++.
In addition to the surface similarities, java shares some of the other attributes that
helped make C and c++ successful. First, java was designed, tested and refined by
real, working programmers. It is a language grounded in the needs of and experiences
of the people who devised it.
CHARACTERSTICS:
SECURITY:
Java compatible browser provides safe downloading of java applets without the
fear of viral infection or malicious intent. Java achieves this protection by confining a
Java program to the java execution environment and by making it inaccessible to
other parts of the computer.
PORTABLE:
In java the same mechanism that gives security also helps in portability. Many
types of computers and operating systems are in use throughout the world and are
connected to the Internet. For downloading programs through platforms connected to
the Internet. Some portable, executable code is needed. Java’s answer to these
problems is its well-designed architecture.

6
OBJECT-ORIENTED:
Java was not designed to be source-code compatible with any other language.
Java team gave a clean, usable, realistic approach to objects. The object model in Java
is simple and easy to extend, while simple types, such as integers, are kept as high-
performance non-objects.
ROBUST:
Java virtually rectifies the problem of memory management by managing
memory allocation and automatic memory deallocation by providing garbage
collection for unused objects. Java also handles exceptional conditions by providing
object-oriented exception handling. In a well-written java program, all run-time errors
can – and should be managed by the program itself.
MULTITHREADED:
Java was designed to meet the real world requirements of creative, interactive,
networked programs. To achieve this, java supports, multithreaded programming,
which allows the user to write programs that perform many functions simultaneously.
The java run-time system enables the user to construct smoothly running
interactive systems; java’s easy-to-use approach to multithreading allows the user to
think about the specific behavior of their programs, not the multitasking subsystem.
DISTRIBUTED:
Java is designed for the distributed environment of the Internet, because it
handles TCP/IP protocols, In fact, accessing a resource using URL is not entirely
different from accessing a file. The original version of Java(OAK) included
DYNAMIC:
Java programs carry with three extensive amounts of run time information’s that
is used to verify and resolve accesses to objects at run time. Using this concept it is
possible to dynamically link code. Dynamic property of java adds strength to the
applet environment, in which small fragments of byte code may be dynamically
updated on a running system.

7
3.2.NETWORKING BASICS:
Java networking allows communication between client and server by enabling
logical sockets using socket-programming interface. Once the socket is enabled
TCP/IP packets can be transferred. Internet protocol (IP) is a low level routing
protocol that breaks data into small packets and sends them to an address across a
network, which does not guarantee to deliver said packets to the destination.
Transmission Control Protocol is a higher-level protocol that manages to robustly
string together these packets, sorting and retransmitting them as necessary to reliably
transmit your data. A third protocol, user data gram protocol (UDP), sits next to TCP
and can be used directly to support fast, connectionless, unreliable transport of
packets.
UNIFORM RESOURCE LOCATER:
The URL provides reasonable intelligible form to uniquely identify or address
information on the Internet. URLs are uniquely identified or address information on
the Internet. URL is ubiquitous; every browser uses them to identify information on
the web. In fact, the web is really just that same old Internet with all of its resources
addressed URLs plus HTML. Within java network class library, the class provides a
simple concise API to access information across the Internet using URLs.
SPECIFICATION:
A URL specification is based on four components. The first is the protocol to
use, common protocols are http. Ftp gopher etc., second component is the host name
or IP address of the host to use; this is delimited on the left by double slashes. The
third component, the port number, is an optional parameter the fourth part is actual
file path.
Java URL class has several constructors, and each can throw a malformed
URL exception. One commonly used form species the URL with a string that is
identical to what we see displayed in a browser.

8
URL CONNECTION:
URL connection is a general-purpose class for accessing the attributes of a
remote resource. Once we make a connection to a remote server, we can use URL
connection to inspect the properties of the remote object before actually transporting it
locally. These attributes are exposed by the remote actually transporting it locally.
These attributes are exposed by the HTTP protocol specification.
INPUT OUTPUT BASICS:
STREAMS:
Java programs perform I/O through streams. A stream is an abstraction that
either produces or consumes information. A stream is linked to a physical device by
the java I/O system. All streams behave in the same manner, even if the actual
physical devices to which they are linked differ. Thus the same I/O classes and
methods can abstract many different kinds of inputs java implements streams within
class hierarchies in the java.io.package.
Java provides two types of streams; byte and character. Byte streams provide a
convenient means for handling input and output of bytes. Byte streams are used for
example, when reading and writing binary data character streams provide a
convenient means for handling input and output of characters. They use Unicode and,
therefore, can be internationalized also, in some cases; characters are more efficient
than byte streams.
3.3.REMOTE FRAME BUFFER:
This is a protocol which is used for VNC; this is a frame relay Buffer which is
used to send the information like frames to the client from the server.
To create a connection between the server and the client there are few methods
that we should follow:
 Protocol Version
 Security
 Authentication
 Server Initialization

9
 Client Initialization
Introduction
RFB (.remote framebuffer.) is a simple protocol
for remote access to graphical user interfaces. Because it works at the
framebuffer level it is applicable to all windowing systems and applications, including
X11, Windows and Macintosh. RFB is the protocol used in VNC (Virtual Network
Computing).
The remote endpoint where the user sits (i.e. the display plus keyboard and/or pointer)
is called the RFB client or viewer. The endpoint where changes to the framebuffer
originate (i.e. the windowing system and applications) is known as the RFB server.
RFB Protocol
RFB is truly a .thin client protocol. The emphasis in the design of the RFB
protocol is to make very few requirements of the client. In this way, clients can run on
the widest range of hardware, and the task of implementing a client is made as simple
as possible.
The protocol also makes the client stateless. If a client disconnects from a
given server and subsequently reconnects to that same server, the state of the user
interface is preserved. Furthermore, a different client endpoint can be used to connect
to the same RFB server. At the new endpoint, the user will see exactly the same
graphical user interface as at the original endpoint. In effect, the interface to the user's
applications becomes completely mobile. Wherever suitable network connectivity
exists, the user can access their own personal applications, and the state of these
applications is preserved between accesses from different locations. This provides the
user with a familiar, uniform view of the computing infrastructure wherever they go.
PROTOCOL MESSAGES
The protocol proceeds to the normal interaction stage after the
ServerInitialisation message. At this stage, the client can send whichever messages it

10
wants, and may receive messages from the server as a result. All these messages begin
with a messagetype byte, followed by any message-speci_c data.
The following descriptions of protocol messages use the basic types U8, U16,
U32, S8, S16, S32. These represent respectively 8, 16 and 32-bit unsigned integers
and 8, 16 and 32-bit signed integers. All multiple byte integers (other than pixel
values themselves) are in big endian order (most signi_cant byte _rst).The type
PIXEL is taken to mean a pixel value of bytesPerPixel bytes, where 8 _bytesPerPixel
is the number of bits-per-pixel as agreed by the client and server .either in the
ServerInitialisation message (section 6.1.5) or aSetPixelFormat message
Initial Handshaking Messages
ProtocolVersion
Handshaking begins by the server sending the client a ProtocolVersion
message. This lets the client know which is the highest RFB protocol version number
supported by the server. The client then replies with a similar message giving the
version number of the protocol which should actually be used (which may be different
to that quoted by the server). A client should never request a protocol version higher
than that offered by the server. It is intended that both clients and servers may provide
some level of backwards compatibility by this mechanism.
The only published protocol versions at this time are 3.3, 3.7, 3.8 (version 3.5
was wrongly reported by some clients, but this should be interpreted by all servers as
3.3). Addition of a new encoding or pseudo-encoding type does not require a change
in protocol version, since a server can simply ignore encodings it does not understand.
The ProtocolVersion message consists of 12 bytes interpreted as a string of
ASCII characters in the format "RFB xxx.yyyn" where xxx and yyy are the major
and minor version numbers, padded with zeros.
No. of bytes Value
12 "RFB 003.003n" (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)
Or

11
No. of bytes Value
12 "RFB 003.007n" (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)
Or
No. of bytes Value
12 "RFB 003.008n" (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)
Security
Once the protocol version has been decided, the server and client must agree
on the type of security to be used on the connection.
Version 3.7 onwards
The server lists the security types which it supports:
No. of bytes Type [Value] Description
1 U8 number-of-security-types
number-of-security-types U8 array security-types
If the server listed at least one valid security type supported by the client, the
client sends back a single byte indicating which security type is to be used on
the connection:
1 U8 security-type
If number-of-security-types is zero, then for some reason the connection failed
(e.g. the server cannot support the desired protocol version). This is followed by a

12
string describing the reason (where a string is specified as a length followed by that
many ASCII characters):
4 U32 reason-length
reason-length U8 array reason-string
The server closes the connection after sending the reason-string.
Version 3.3 The server decides the security type and sends a single word:
4 U32 security-type
The security-type may only take the value 0, 1 or 2. A value of 0 means that
the connection has failed and is followed by a string giving the reason, as described
above.
The security types they_need in this document are:
Number Name
0 Invalid
1 None
2 VNC Authentication
Other registered security types are:

13
Number Name
5 RA2
6 RA2ne
16 Tight
17 Ultra
18 TLS
Once the security-type has been decided, data speci_c to that security-type follows At
the end of the security handshaking phase, the protocol normally continues with the
SecurityResult message.
Note that after the security handshaking phase, it is possible that further
protocol data is over an encrypted or otherwise altered channel.
SecurityResult
The server sends a word to inform the client whether the security handshaking
was successful.
4 U32 status:
0 OK
1 failed
If successful, the protocol continues with the ClientInitialisation message.
Version 3.8 onwards If unsuccessful, the server sends a string describing the reason
for the failure, and then closes the connection:

14
4 U32 reason-length
reason-length U8 array reason-string
Version 3.3 and 3.7 If unsuccessful, the server closes the connection.
ClientInitialisation
Once the client and server are sure that they're happy to talk to one another
using the agreed security type, the client sends an initialisation message:
1 U8 shared-flag
Shared-flag is non-zero (true) if the server should try to share the desktop by
leaving other clients connected, zero (false) if it should give exclusive access to this
client by disconnecting all other clients.
ServerInitialisation
After receiving the ClientInitialisation message, the server sends a
ServerInitialistion message. This tells the client the width and height of the server's
framebuffer, its pixel format and the name associated with the desktop:
2 U16 framebuffer-width
2 U16 framebuffer-height
16 PIXEL_FORMAT server-pixel-format
4 U32 name-length
name-length U8 array name-string

15
where PIXEL_FORMAT is
1 U8 bits-per-pixel
1 U8 depth
1 U8 big-endian-flag
1 U8 true-colour-flag
2 U16 red-max
2 U16 green-max
2 U16 blue-max
1 U8 red-shift
1 U8 green-shift
1 U8 blue-shift
3 padding
Server-pixel-format speci_es the server's natural pixel format. This pixel
format will be used unless the client requests a different format using the
SetPixelFormat message
Bits-per-pixel is the number of bits used for each pixel value on the wire. This
must be greater than or equal to the depth which is the number of useful bits in the
pixel value. Currently bits-per-pixel must be 8, 16 or 32. less than 8-bit pixels are not
yet supported. Big-endian-flag is non-zero (true) if multi-byte pixels are interpreted as
big endian. Of course this is meaningless for 8 bits-per-pixel.
If true-colour-flag is non-zero (true) then the last six items specify how to
extract the red, green and blue intensities from the pixel value. Red-max is the
maximum red value (= 2n � 1 where n is the number of bits used for red). Note this
value is always in big endian order. Red-shift is the number of shifts needed to get the
red value in a pixel to the least signi_cant bit. Green-max, green-shift and blue-max,

16
blue-shift are similar for green and blue. For example, to _nd the red value (between 0
and red-max) from a given pixel, do the following:
 Swap the pixel value according to big-endian-flag (e.g. if big-endian-flag is
zero (false) and host byte order is big endian, then swap).
 Shift right by red-shift.
 AND with red-max (in host byte order).
If true-colour-flag is zero (false) then the server uses pixel values which are not
directly composed from the red, green and blue intensities, but which serve as indices
into a colour map. Entries in the colour map are set by the server using the
SetColourMapEntries message.
Security Types
None
No authentication is needed and protocol data is to be sent unencryptyed.
VNC Authentication
VNC authentication is to be used and protocol data is to be sent unencryptyed.
The server sends a random 16-byte challenge:
16 U8 challenge
The client encrypts the challenge with DES, using a password supplied by the
user as the key, and sends the resulting 16-byte response:
16 U8 response
The protocol continues with the SecurityResult message.

17
4.PROJECT DESIGN
4.1 UML DIAGRAMS
A Diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and arcs (relationships).For this
reason, and the UML includes nine such diagrams.
The Unified Modelling Language (UML) is probably the most widely known and
used notation for object-oriented analysis and design. It is the result of the merger of
several early contributions to object-oriented methods. The Unified Modelling
Language (UML) is a standard language for writing software blueprints? The UML
may be used to visualize, specify, construct, and document the artefacts. A Modelling
language is a language whose vocabulary and rules focus on the conceptual and
physical representation of a system. Modelling is the designing of software
applications before coding. Modelling is an Essential Part of large software projects,
and helpful to medium and even small projects as well. A model plays the analogous
role in software development that blueprints and other plans (site maps, elevations,
physical models) play in the building of a skyscraper. Using a model, those
responsible for a software development project's success can assure themselves that
business functionality is complete and correct, end-user needs are met, and program
design supports requirements for scalability, robustness, security, extendibility, and
other characteristics, before implementation in code renders changes difficult and
expensive to make.
The underlying premise of UML is that no one diagram can capture the different
elements of a system in its entirety. Hence, UML is made up of nine diagrams that can
be used to model a system at different points of time in the software life cycle of a
system. The nine UML diagrams are:

18
Use case diagram
The use case diagram is used to identify the primary elements and processes
that form the system. The primary elements are termed as "actors" and the processes
are called "use cases." The use case diagram shows which actors interact with each
use case.
Class diagram
The class diagram is used to refine the use case diagram and define a detailed
design of the system. The class diagram classifies the actors defined in the use case
diagram into a set of interrelated classes. The relationship or association between the
classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram
may be capable of providing certain functionalities. These functionalities provided by
the class are termed "methods" of the class. Apart from this, each class may have
certain "attributes" that uniquely identify the class.
Object diagram
The object diagram is a special kind of class diagram. An object is an instance
of a class. This essentially means that an object represents the state of a class at a
given point of time while the system is running. The object diagram captures the state
of different classes in the system and their relationships or associations at a given
point of time.
State diagram
A state diagram, as the name suggests, represents the different states that
objects in the system undergo during their life cycle. Objects in the system change
states in response to events. In addition to this, a state diagram also captures the
transition of the object's state from an initial state to a final state in response to events
affecting the system.

19
Activity diagram
The process flows in the system are captured in the activity diagram. Similar
to a state diagram, an activity diagram also consists of activities, actions, transitions,
initial and final states, and guard conditions.
Sequence diagram
A sequence diagram represents the interaction between different objects in the
system. The important aspect of a sequence diagram is that it is time-ordered. This
means that the exact sequence of the interactions between the objects is represented
step by step. Different objects in the sequence diagram interact with each other by
passing "messages".
Collaboration diagram
A collaboration diagram groups together the interactions between different
objects. The interactions are listed as numbered interactions that help to trace the
sequence of the interactions. The collaboration diagram helps to identify all the
possible interactions that each object has with other objects.
Component diagram
The component diagram represents the high-level parts that make up the
system. This diagram depicts, at a high level, what components form part of the
system and how they are interrelated. A component diagram depicts the components
culled after the system has undergone the development or construction phase.
Deployment diagram
The deployment diagram captures the configuration of the runtime elements
of the application. This diagram is by far most useful when a system is built and ready
to be deployed. Now that we have an idea of the different UML diagrams, let us see if
we can somehow group together these diagrams to enable us to further understand
how to use them.

20
4.1.1.Usecase diagram
receives ip address & port no
checks the validity of clent
allows client to capture desktop
screens stored in the form of frames
server
data transfered in encrypted form

21
send ip address & port no
connection established
receives desktop server in frames
client
decrypts the received data

22
4.1.2.Sequence diagram
s:VNCservers:VNCserverc:VNCclientc:VNCclient
1: sends ip address & port no
2: receives ip address & port no
3: checks the validity of client
4: connection established
5: capture the desktop in the form of frames
6: data stored in encrypted format
7: allows the client to access the frames
8: decrypts the data

23
4.1.3.Collaboration diagram
c:VNCcli
ent
s:VNCse
rver
1: sends ip address & port no
2: receives ip address & port no
3: checks the validity of client
4: connection established
5: capture the desktop in the form of frames
6: data stored in encrypted format
7: allows the client to access the frames
8: decrypts the data

25
4.1.5.State chart
Idle
Active
Client enters
ip,port
connect
with server server stores
content in frames
frames in
encrypted format
client decrypts
the content can view the
server desktop
Client enters
ip,port
connect
with server
valid
invalid
server stores
content in frames
frames in
encrypted format
client decrypts
the content can view the
server desktop

26
4.1.6.Activity diagram
client
send Ipaddress
& port no
connect
valid
receives the desktop
server in form of frames
decrypts the
received date
noyes

27
server
Receives Ipaddress
& port no
checks validity of client
allows client to
capture desktop
screens are stored
in form of frames
stored data transfered
in encrypted form
yes
no
server-pcclient-pc
sends
ip&port
connect
with server
receives desktop
server in frames
decrypts the
received data
receives
ip&port
allows client
to capture
screens stored
in frames
store data in
encrypt format

28
4.2. Data Flow Diagrams:
A data flow diagram (DFD) shows how data moves through an information system
but does not show program logic or processing steps. DFDs represent a logical model that
shows what the system does, not how it does it.
DFD Symbols:
DFDs use four basic symbols that represent processes, data flows, data stores, and
external entities.
 Process symbol.
 Data flow symbol.
 Data store symbol.
 External entity symbol.
Process symbol:
A process receives input data and produces output that has a different content, form,
or both.
The symbol for a process is a rectangle with rounded corners. The name of the
process appears inside the rectangle.
Process
Data Flow symbol:
A data flow is a path for data to move from one part of the information system to
another. A data flow in a DFD represents one or more data items or it could represent a set
of data.

29
The symbol for a data flow is a line with a single or double arrowhead. The data
flow name appears above, below, or alongside the line.
Dataflow
Data Store symbol:
A data store, or a data repository, is used in a DFD to represent a situation in which
the system must retain data because one or more processes need to use the stored data at a
later time.
The symbol for a data store is a flat rectangle that is open on the right side and
closed on the left side the name of the data appears between the lines and identifies the data
it contains.
Data store
External entity:
An external entity is a person, department, outside organization, or other
information system that provides data to the system or receives output from the system.
External entities also are called terminators, because they are data origins or final
destinations.
External Entity

30
LEVELS OF ABSTRACTION:
Level 0
The Highest level DFD is Level 0.It shows the entire application as a single
process surrounded by its data stores and is sometimes known as context diagram.
Level 1
It shows the whole application again but with the main processes, the data
flows between them and their I individual links the data stores.
Level 2
Each process from level 1 is expanded into its own level 2 diagram and then
into lower level diagram to show further detail. Process no 1 at level 1 would be
expanded into processes 1.1, 1.2, 1.3, etc... At level 2.
Data stores remain the same at all levels of abstraction but new stores may be
introduced at any level. These are usually temporary stores such as views and cursors
which are required in lower level processes.
Level 0:-
Remote processing
Client Server

31
Level 1:-
Checking
Validity
Message
Client
IP address
Port number
Server
Request
Valid message
Encrypted
Message
Decrypts msg

32
Level 2:-
Level 2:-
Cipher text
Key
Decryption
XOR
Plain Text
XOR
Encryption Cipher text
Plain Text
Key

33
4.3. Software flow diagrams
FLOWCHART CLIENT SIDE:
START
IF VALID
CONNECTION
IS
ESTABLISHED
SEND IPADDRESS &
PORT NUMBER
po
PORT NUMBER
RECEIVES THE DESKTOP OF SERVER
IN FORM OF FRAMES
STOP
YES
NO
DECRYPTS THE RECEIVED
DATA BY USING DES ALG

34
`
FLOWCHART SERVERSIDE:
START
RECEIVES IP ADDRESS &
PORT NUMBER
PORT NUMBER OF CLIENT
CHECKS
VALIDITY OF
CLIENT
ALLOWS CLIENT TO CAPTURE
DESKTOP
SCREENS ARE STORED IN THE
FORM OF FRAMES USING RFB
THE STORED DATA IS TRANAFERRED
IN ENCRYPTED FORM
STOP
YES
NO

35
5. ARCHITECTURE
Client/server architecture:-
The term client/server architecture generally refers to system that divide processing
between one or more networked clients and a central server. In a typical client/server
system, the client handles the entire user interface, including data entry, data query, and
screen presentation logic. The server stores the data and provides data access and database
management functions.
In a client/server interaction, the client submits a request for information from the
server, which carries out the operation and responds to the client.
Characteristics of client/server architecture
Basic architecture : Very flexible
Application : Flexible, Fast, Object oriented
Development
User environment : PC based, GUI, Empowers the user
Improves productivity
Security and control : Decentralized
Features Difficult to control
Processing option : can be shared and configured
In any form desired
Client Server
Client sends a request
Server process the request

36
Data store options : Can be distributed to place data to closer to users
Hardware/Software : very flexible multivendor model
Integration
In regard with project:
Mainly the project requires two modules i.e, client and server. So that we require client-
server architecture in which client will capture the desktop of server.
The client/server Architecture
Client message
Server message
Client
AuthenticationClient unit
Processing Server unit
processing
Server

37
5.3. Algorithm for client & Server:-
STEP 1:- START
STEP 2:-LAN connection is set up by using two system i.e, client and server.
STEP 3:-Client login by sending IP Address and port number to the server
STEP 4:-Validity of client is checked by server
STEP 5:-IF valid GOTO step 6 else step 15.
STEP 6:-server allows the client to capture the desktop.
STEP 7:-client captures the desktop in the form of frames by using RFB protocol.
STEP 8:- GOTO step13
STEP 9:-Changes at the server/client desktop are stored in the frame buffer
STEP 10:-the updated frame buffer is sent to the client/server to redrawn the desktop.
STEP 11:-the captured data is encrypted and the data is sent by using TCP/IP
protocol.
STEP 12:- the client receives the data in encrypted form.
STEP 13:- if any changes at the client/server side, GOTO step 9.
STEP 14:- the client decrypts the data by using DES algorithm.
STEP 15:- stop

38
6.PROJECT TESTING
6.1 INTRODUCTION OF TESTING
Testing is the process of detecting errors. Testing performs a very critical role
for quality assurance and for ensuring the reliability of software. The results of testing
are used later on during maintenance also.
Psychology of Testing
The aim of testing is often to demonstrate that a program works by showing that it has
no errors. The basic purpose of testing phase is to detect the errors that may be present
in the program. Hence one should not start testing with the intent of showing that a
program works, but the intent should be to show that a program doesn’t work. Testing
is the process of executing a program with the intent of finding errors.
6.2 TESTING OBJECTIVES
The main objective of testing is to uncover a host of errors, systematically and
with minimum effort and time. Stating formally, we can say,
 Testing is a process of executing a program with the intent of finding an
error.
 A successful test is one that uncovers an as yet undiscovered error.
 A good test case is one that has a high probability of finding error, if it
exists.
 The tests are inadequate to detect possibly present errors.
 The software more or less confirms to the quality and reliable standards.
6.3 Types of Testing:
There are various types of testing.
 Unit Testing
 System Testing

39
 Acceptance Testing
 Integration testing
Unit Testing:
In unit testing the analyst‘s tests the programs making up a system. The
software units in the system are the modules and routines that are assembled and
integrated to perform a specific function. In large system, many modules at different
levels are needed.
Unit Testing individually focuses on the modules. This enables the tester to
detect errors in coding and logic that are contained within the module alone. The
errors resulting from the interaction between the modules are initially ignored.
Unit testing can be performed in bottom-up approach, starting with
smallest/lowest module and processing one at a time. For each module in bottom-up
testing, a short program executes the module and provides the needed data, so that the
module is asked to perform the way it will be embedded within the larger system.
When bottom level modules are tested, attention turns to those on next level that uses
these lower level ones. They are tested individually and then linked with the
previously examined lower level modules.
Top-down testing, as the name implies, begins with the upper-level modules.
However, since the detailed activities are usually performed in lower-level routines,
that are not provided, studs are written. A stud is module shell that can be called by
the upper-level module and that, when reach properly, will return a message to calling
module, indicating the correctness of lower-level module.
Often top-down testing are combined with bottom-up testing, that is, some
lower-level module are unit tested and integrated into top-down testing program.
System Testing:
Systems testing do not test the software per se but rather the integration of
each module in the system. It also tests to find discrepancies between the system and
its original objectives, current sections and system documentation. The primary
concern is the compatibility of individual modules. Analysts are trying to find areas

40
where modules have been designed with different specifications for data length, type
and data element name.
Acceptance Testing:
The software has been tested with the realistic data given by the
client and produced fruitful results. The client satisfying all the requirements specified
by them has also developed the software within the time limitation specified. A
demonstration has been given to the client and the end-user giving all the operational
features.
Integration Testing:
Integration testing is a systematic technique for constructing
the program structure while conducting tests to uncover errors associated with
interfacing. The objective is to take unit tested modules and build a program structure
that has been dictated by design.
Code Testing:
This strategy examines the logic of the program. To follow this
method we developed some test data that resulted in executing every instruction in the
program and module i.e. every path is tested. Systems are not designed as entire nor
are they tested as single systems. To ensure that the coding is perfect two types of
testing is performed or for that matter is performed or that matter is performed or for
that matter is performed on all systems.

41
OUTPUT SCREENS
Client side screens:
Connection Setup:-
Connecting to the server while setting up we have to give the IP address of the server
and port number of the server.

42
Login page:
login page to connect to the server, in the password box we have to give the password
of the vnc server.

43
Options:
By option window we can adjust the setting of the pixel,quality,color,mouse buttons
can be adjusted and change the encoding options.

44
Clipboard:
By using clip board we can write notes like a notepad software.

45
Recording:
Using recording option we can record the session and save

46
Send Ctrl-Alt-Delete:
Using Ctrl-Alt-Delete option we can manage the server computer and can check
rectify the errors.

47
Disconnect:
With disconnect client can disconnect the active session.

48
Server Desktop
The desktop at server side

49
Captures Desktop:
The desktop at client side consist of captured desktop of server.

50
CONCLUSION
The project goal is to provide simultaneous, collaborative, remote control of the
server in GSS. A network based solution eliminates the need for the clients to travel to
the server.
It is used for presentations with in a Local Area Network. On the system,
which desktop user requires, the server should be started. On the client we develop an
application using which the user can view the desktop of that system.

51
BIBILOGRAPHY
Web sites:
 www.java2s.com
 www.sun.java.com
 www.realvncserver.com
Text books referred:
 Java The Complete Reference by Herbert Schildt.
 Systems Analysis and Design by Shelly/Cashman/Rosenblatt.
 Software Engineering by S.Rogers Pressmen.

Remote Web Desk

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Remote Web Desk

Ähnlich wie Remote Web Desk (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Remote Web Desk