Download Comparing file transfer and encryption performance of Java

Universiteit Antwerpen (UA)
Faculteit Wetenschappen
Departement Wiskunde – Informatica
Academiejaar 2003 – 2004
Comparing file transfer and encryption performance
of Java and .NET
Eindverhandeling ingediend door
Bert JAGERS
Tot het bekomen van het diploma van
Aanvullende Studie informatica en bedrijfswiskunde (ASIB)
Zwaartepunt Informatica
Promotor: Prof. Dr. S. Demeyer
Begeleider: A. Zaidman
1 Acknowledgements
This year has been a very though but interesting year. Being a Biologist and
considering that I only have programmed my first letter of code about a year
ago, this year was kind of a giant leap in the dark. I owe the fact that I made it
through alive, much more experienced and grown up, to a lot of people. I
would like to express my gratitude to them here.
First of all, I would like to thank Prof. Dr. Serge Demeyer (UA, LORE) for
giving me the chance to complete this thesis and for acquiring an enormous
amount of knowledge and a interesting but realistic view to the world of
Informatics and Software Engineering by doing so. Second of all I would
definitely like to thank Andy Zaidman (UA, LORE) who has guided me through
this thesis in a superb way. The fact that he was always there when you
needed advice or an answer to a question, and the fact that he did so with a
lot of patience, has been a great help to me.
Since I couldn’t bother Andy the whole time, Sarah Teugels, who has been an
enormous help to me, also definitely deserves a special place here. By giving
me a lot of practical advice, in a way that I could solve my problem(s), or
sometimes by organizing a “debugging session” together, I came to where I
am now. I will always be grateful for the help and the patience she has given
me this year and for the knowledge she has passed on to me.
I would also like express my gratitude to my fellow students for the help they
gave me this year, and especially Wouter Cuypers who has provided me with
great advice and interesting points of view that helped me to tackle some of
the problems I was experiencing.
My family deserves a lot of thanks for the support and understanding they
have given me throughout this year. Although I may not always show it, know
that I have really appreciated it. A special word of thanks to my parents for
2
giving me all the chances and opportunities that made me the person I am
today.
And last but definitely not least, I would like to thank my fiancée Kristin for
putting up with me through this difficult year, for supporting me when things
didn’t seem to go that well and for enduring the many times I couldn’t be there
for her due to an awful lot of work for school…
This thesis is the result of my labor and I will take full responsibility for it.
3
2 Samenvatting
Met de introductie van Microsoft’s .NET Framework in 2000, heeft het Java
Platform van Sun Microsystems er een geduchte concurrent bij gekregen.
Sindsdien beconcurreren zij elkaar voor de leidende positie in de markt van
de software ontwikkelingsomgevingen. Beiden bekleden elk tegenwoordig
een marktaandeel van om en bij de 35 à 40% waardoor geen van beide
geneigd is om spoedig te verdwijnen.
Een andere interessante trend is de grote groei, zowel in aantal als in
populariteit, van de Peer-to-Peer (P2P) applicaties. Deze trend past perfect in
de huidige maatschappij waarin het digitaal verzenden van (gevoelige) data
over netwerken steeds grotere proporties aanneemt. P2P applicaties kunnen
deze processen zeker vergemakkelijken maar een goed beveiliging van de te
versturen data is absoluut onontbeerlijk.
De thesis bevat een korte beschrijving van de twee platformen en de twee
talen gebruikt voor de programmering van de applicaties, zijnde Java voor het
Java Platform en C# voor het .NET Framework. Vervolgens worden de twee
platformen op basis van verschillende kenmerken met elkaar vergeleken. Dit
gebaseerd op de reeds bestaande literatuur.
Eén van de twee hoofddoelen van deze thesis is onderzoeken in hoeverre de
performantie van de transfer van bestanden via een P2P applicatie verschilt
tussen het .NET Framework en het Java Platform. Hiervoor werden twee
identieke P2P applicatie gecreëerd die in staat waren om via Multicasting over
een lokaal netwerk, gebruik makend van het User Datagram Protocol (UDP),
in contact te staan met elkaar. Bestanden kunnen vervolgens verstuurd
worden via het Transmission Control Protocol (TCP) en dit volledig P2P,
zonder dat er een externe Server nodig is.
De testen worden vooraf gegaan door een algemene inleiding waarin
gekeken wordt wat P2P is en in hoeverre beide platformen hiervoor een
ondersteuning bieden.
4
Het tweede hoofddoel van deze thesis is het vergelijken van de performantie
van de symmetrische encryptie tussen beide platformen. Hiervoor werden
twee symmetrische encryptie algoritmen geselecteerd: het TripleDES
algoritme en het AES of Rijndael algoritme. In de beide programmeertalen
werden er twee applicaties ontwikkeld, één voor elk encryptie algoritme, die in
staat waren om een bestand in te lezen en te encrypteren of decrypteren.
Vervolgens moesten deze applicaties bestanden van een bepaalde grootte
encrypteren en decrypteren. De snelheid waarmee ze dit deden werd
genoteerd. Ook hier worden de testen vooraf gegaan door een algemene
inleiding omtrent symmetrische encryptie en een korte bespreking van de
twee gebruikte algoritmen.
De performantie van beide platformen blijkt gelijk te liggen wanneer we de
transfer van bestanden via een P2P applicatie in beschouwing nemen. In C#
is het echter mogelijk om de snelheid van het sturen en ontvangen van
bestanden gevoelig te verhogen door de bestanden ongebufferd te
verzenden, gebruik makend van de TcpClient class. Het bufferen van
bestanden is echter nodig om interoperabiliteit tussen de Java applicatie en
de C# applicatie te kunnen verzekeren. Bufferen heeft als extra voordeel dat
de gehele file niet eerst volledig moet worden ingelezen alvorens de applicatie
kan beginnen encrypteren/decrypteren. Dit spaart geheugen uit dat dan
gebruikt kan worden voor andere applicaties/processen.
Wat betreft de performantie van de symmetrische encryptie van beide
platformen is het duidelijk dat C# gevoelig sneller encrypteert gebruik makend
van het TripleDES algoritme. Het omgekeerde is waar voor het AES
algoritme, met uitzondering voor de encryptie van grote bestanden (+/100Mb) waarbij de C# applicatie sneller is.
Wederom kunnen we in beschouwing nemen dat moderne applicaties eerder
geneigd gaan zijn om bestanden stukje per stukje in te lezen (in een stream)
waarbij deze stukjes dan geencrypteerd worden vanaf de moment dat ze zijn
ingelezen. Dit spaart geheugen en maakt dat het proces van encryptie sneller
kan verlopen. Daardoor moeten er dus steeds enkel maar kleine stukjes
5
geencrypteerd worden. Voor het encrypteren van kleine bestanden is de
performantie van beide platformen echter gelijk.
Beide platformen blijken even performant te presteren wat betreft het
verzenden en ontvangen van bestanden via een P2P applicatie en wat betreft
symmetriche encryptie (met betrekking tot de beschouwde algoritmen).
Beiden lijken dus adequaat voor de constructie van veilige, efficiënte P2P
applicaties.
6
3 Abstract
To date, Microsoft’s .NET Framework and Sun’s Java Platform compete for
the leading position in the market of software development environments.
They try to provide an environment to developers that ensures secure, fast
and reliable development.
Another important trend is the growing number of Peer-to-Peer applications
(P2P) used for the transport of data.
This thesis will, after a short comparison of both platforms, try to evaluate the
performance of both platforms, taking file transfer through a P2P application
and symmetric encryption (the TripleDES algorithm and the AES algorithm)
into consideration. This may show which platform can be preferred for the
development of reliable, fast and secure P2P applications.
7
4 Index
1
Acknowledgements...................................................................................2
2
Samenvatting............................................................................................4
3
Abstract ....................................................................................................7
4
Index.........................................................................................................8
5
Introduction .............................................................................................10
6
7
8
9
5.1
Java and C#, (not) a world of differences? ......................................10
5.2
Overview of this thesis.....................................................................11
Introducing Java and the Java VM..........................................................12
6.1
The History of Java..........................................................................12
6.2
The Java Platform ...........................................................................13
6.3
The Java Virtual machine ................................................................14
6.4
The Java programming Language...................................................16
Introducing C# and the .NET Framework ...............................................18
7.1
The History of .NET and C#.............................................................18
7.2
The .NET Framework ......................................................................20
7.3
The C# programming language .......................................................22
A first small comparison based on known facts ......................................25
8.1
Syntax..............................................................................................25
8.2
Virtual machines and portable code ................................................26
8.3
Portability.........................................................................................27
8.4
Standardization................................................................................28
8.5
Security............................................................................................28
The Applications .....................................................................................31
9.1
The P2P Application ........................................................................31
9.2
The applications for encryption........................................................32
10 Using a P2P messenger for performance measurements. .....................33
10.1
What is peer-to-peer?......................................................................33
10.1.1
An overview..............................................................................33
10.1.2
Java vs. .NET ...........................................................................35
10.2
How do we measure performance? .................................................38
10.3
Results of the P2P performance test ...............................................39
8
10.4
Discussion of the results..................................................................42
11 Using symmetric encryption for performance measurements. ................44
11.1
What is symmetric encryption?........................................................44
11.1.1
An overview..............................................................................44
11.1.2
The TripleDES algorithm ..........................................................47
11.1.3
AES or the Rijndael algorithm ..................................................48
11.2
How do we measure performance? .................................................49
11.3
Results of the symmetric encryption test .........................................50
11.4
Discussion of the results..................................................................54
12 Conclusions: The performance of Java and .NET ..................................56
12.1
Which platform/language for P2P applications? ..............................56
12.2
Which platform/language for symmetric encryption? .......................56
12.2.1
Memory management...............................................................56
12.2.2
Which platform to choose? .......................................................57
12.3
The General Conclusion and remarks for the future. .......................58
13 References .............................................................................................60
Appendix A: A list of used abbreviations........................................................66
Appendix B: The StopWatch class.................................................................67
9
5 Introduction
5.1 Java and C#, (not) a world of differences?
Since the introduction of C# and the .NET framework in 2000 by Microsoft,
Java and its Java Virtual machine, for the first time, experienced a serious
competitor. Both platforms grew in popularity over the last few years and both
have their own share of followers and opposition, mostly the followers of one
platform are against the other, resulting in lots of discussions on why “their”
platform is better.
Either way, the enterprise development market share of both platforms lies
around 35 - 40% each. It's fairly obvious that neither of these two platforms is
"going away" any time soon. [Neward, 2004].
Therefore it might be interesting to see how performant both of this platforms
are. Comparing both platforms on each and every aspect would of course be
to much work for just one thesis. It can’t be done by one person in one year.
Therefore, this thesis will emphasize two aspects of both platforms. The two
questions this thesis tries to answer are:
•
Peer – to – peer (P2P) networking: Which platform has the ability to
deliver the most performant file sharing? Which has the fastest
multicast broadcasts?
•
Symmetric encryption: Which platform can run a selected symmetric
algorithm the fastest? Does this result still apply to another symmetric
algorithm?
Both questions are very relevant in this context. Looking at the growing
number and popularity of P2P applications (like ICQ, Gnutella, Kazaa, …),
people need fast and safe applications for the transport of sensitive and
secure data. Both Java and .NET offer the means for the creation of these
applications. It would be very interesting to see which platform can offer the
most performant ones.
By developing the same P2P application, that is capable of broadcasting over
UDP and transfer of encrypted files over TCP in Java and C#, and by doing
10
performance tests on both, we will try to give a solid answer to these
questions.
5.2 Overview of this thesis
This thesis starts by introducing the two languages Java and C#, and their
respective platforms: the Java platform and the .NET Framework (chapters 6
and 7). After this general introduction we do a first comparison of Java and C#
and their platforms (chapter 8). This comparison is based on differences and
similarities that are already described in existing literature. Special attention is
given to a first comparison regarding security.
In chapter 9, the reader will find a short description of the applications created
for the performance measuring. Two features will be examined: Peer-to-peer
(P2P) networking and symmetric encryption. Chapter 10 starts with a short
introduction on P2P networking, followed by a performance test. It ends with a
summary of the results of this test. The same is done for Symmetric
encryption (chapter 11).
In the last chapter, a discussion on the performance of Java and C#/.NET, the
reader will find a discussion of the results of chapter 10 and 11. A general
conclusion will be drawn and a few remarks for the future will end this last
chapter.
11
6 Introducing Java and the Java VM
6.1 The History of Java
The birth of Java started out as a part of a larger project to develop advanced
software for consumer electronics: The Green project. These devices are
small, reliable, portable, distributed, real-time embedded systems. But at first,
creating a new language wasn't even the point of "the Green Project.". When
they started the project, the intention was to use C++, but they encountered a
number of problems. Initially these were just compiler technology problems,
but as time passed the designers discovered that C++ couldn’t respond to the
requirements of the systems they were writing software for. These problems
were best solved by changing the language [Sun, 95].
Java technology was created as a programming tool in a small, closed-door
project initiated by Patrick Naughton, Mike Sheridan, and James Gosling of
Sun in 1991.
Back in the early nineties, the Internet was becoming popular as a way of
moving media content -- text, graphics, video -- throughout a network of
heterogeneous devices using HTML. Java technology had been designed in
parallel to move media content across networks of heterogeneous devices,
but it also offered the capability to move "behavior" in the form of applets
along with the content. HTML alone could not do that, but it did set the stage
for Java technology. This resulted in the HotJava browser around 1994.
On May 23, 1995, John Gage, director of the Science Office for Sun
Microsystems, and Marc Andreessen, cofounder and executive vice president
at Netscape, stepped onto a stage and announced to the SunWorld audience
that Java technology was real, it was official, and it was going to be
incorporated into Netscape Navigator [Byous, 1998].
After this, Java quickly became very popular and to date is being used for the
creation of many applications on many different platforms.
12
6.2 The Java Platform
It is important to understand what is meant by the term platform. To a
computer programmer, a platform is defined by the application programming
interfaces (APIs) he or she can rely on when writing a program. These APIs
are usually defined by the operating system of the target computer. Thus, a
programmer writing a program to run under Microsoft Windows must use a
different set of APIs than a programmer writing the same program for the
Macintosh or for a Unix-based system. In this respect, Windows, Macintosh
and Unix are three distinct platforms.
Apart from these OS related APIs, Java also contains lists, vectors and lots of
other things that cannot be found in most other languages.
Fig. 1: The Java 2 Platform SE version 1.4 as described in [Sun, 2004a]
The Java platform is just as important as the Java programming language or
the virtual machine. All programs written in the Java language rely on the set
of predefined classes (Java Class Libraries or JCL) that are included in the
Java platform. Java classes are organized into related groups known as
13
packages. The Java platform defines packages for functionality such as
input/output (I/O), networking, graphics, user-interface (UI) creation, security
and much more.
Java is not an operating system. Nevertheless, the Java platform provides
APIs with a comparable depth to those defined by an operating system. With
the Java platform, you can write applications in Java without sacrificing the
advanced features available to programmers writing native applications
targeted at a particular underlying operating system. An application written on
the Java platform runs on any operating system that supports the Java
platform. This means you do not have to create distinct Windows, Unix or
Macintosh versions of your programs, for example. A single Java program
runs on all these operating systems, which explains why “Write once, run
anywhere” is Sun’s motto for Java [Flanagan, 2002].
6.3 The Java Virtual machine
The Java Virtual Machine (JVM) or Java interpreter, is the crucial piece of
every Java installation. By design, Java programs are portable, but they are
only portable to platforms to which the Java interpreter is ported. Sun ships
JVM implementations for its own Solaris operating system and for Microsoft
Windows and Linux platforms. Many other vendors, including Apple and
various commercial Unix vendors, provide Java interpreters for their
platforms. The JVM is not only for desktop systems however. It had been
ported to set-top boxes, and scaled down versions are even available for
hand-held devices that run Windows CE and PalmOS.
Since there are so many different target operating systems, it is logical that
Java is available in many different forms. Sun alone provides four different
Java 2 platforms, all containing a Virtual Machine but different in size, target
and possibilities (http:// java.sun.com):
•
Java 2 Platform, Standard Edition Tools (J2SE): There are two
principal products in the J2SE platform family: Java 2 Runtime
14
Environment,
Standard
Edition
(JRE)
and
Java
2
Software
Development Kit, Standard Edition (SDK). The JRE provides the Java
APIs, Java virtual machine, and other components necessary to run
applets and applications written in the Java programming language.
The JRE does not contain tools and utilities such as compilers or
debuggers
for
developing
applets
and
applications.
The Java 2 SDK is a superset of the JRE, and contains everything that
is in the JRE, plus tools such as the compilers and debuggers
necessary for developing applets and applications (fig. 1) [Sun, 2004
a].
•
Java 2 Platform, Enterprise Edition Tools (J2EE): The Java 2 Platform,
Enterprise Edition (J2EE) defines the standard for developing multi-tier
enterprise applications. It takes advantage of many features of the
Java 2 Platform, Standard Edition (J2SE). Building on this base, the
Java 2 Platform, Enterprise Edition adds full support for Enterprise
JavaBeans components, Java Servlets API, JavaServer Pages and
XML technology [Sun, 2004b].
•
Java 2 Platform, Micro Edition Tools (J2ME): The Java 2 Platform,
Micro Edition (J2ME) provides a robust, flexible environment for
applications running on consumer devices, such as mobile phones,
PDAs, and TV set-top boxes, as well as a broad range of embedded
devices. J2ME includes Java virtual machines and a set of standard
Java APIs defined through the Java Community Process, by expert
groups whose members include leading device manufacturers,
software vendors, and service providers [Sun, 2004c].
•
Java Card Tools: Java Card technology enables smart cards and other
devices with very limited memory to run small applications, called
applets, that employ Java technology. The technology enables
developers to build, test, and deploy applications and services rapidly
and securely. This accelerated process reduces development costs,
increases product differentiation, and enhances value to customers. In
a manner complementary to the Standard, Enterprise, and Mobile
editions of the Java 2 Platform, Java Card technology makes it easy to
15
integrate security tokens into a complete Java software solution [Sun,
2004d].
As already stated, other vendors have their own JVM and can be considered
as competition for Sun on the enterprise level. IBM’s WebSphere is an
example. It contains its own JVM that is not Sun’s. There are also alternatives
to Sun’s JVM made by the open source community. A good example here is
Kaffe (www.kaffe.org).
Although interpreters are not typically considered to be high-performance
systems, JVM performance is remarkably good and has been improving
steadily. Of particular note is the VM technology called Just-In-Time (JIT)
compilation, whereby Java byte codes are converted on-the-fly into nativeplatform machine language, boosting execution speed for code that is run
repeatedly [Flanagan, 2002].
The 1.4.1 version of the Java HotSpot VM (as shown in fig. 1) builds on a
strong
foundation
of
features
and
capabilities,
assuring
scalability,
performance, reliability, and serviceability (RAS) [Sun, 2002b].
6.4 The Java programming Language
Java is said to be a simple, object-oriented, distributed, interpreted, robust,
secure, architecture neutral, portable, high-performance, multi-threaded and
dynamic language [Sun95]. Its syntax is similar to that of C. The designers
strove to make the Java language powerful, but, at the same time, they tried
to avoid the overly complex features that have bogged down other objectoriented languages, such as C++. By keeping the language simple, the
designers also tried to achieve that it became easier for programmers to write
robust, bug-free code.
Some of the key benefits of Java are described next:
•
“Write once, run anywhere”: For Sun this became the core value
proposition of the Java platform. It means that the most important
promise of the Java technology is that you only have to write your
16
application once – for the Java platform – and then you’ll be able to run
it anywhere. That is, anywhere that supports the Java platform. By
now, Java support is being integrated in almost any operating system.
•
Security: Both the language and the platform were designed with
security in mind. The Java platform allows users to download untrusted
code over a network and run it in a secure environment in which it
cannot do any harm.
•
Network-centric programming: “The Network is the computer”. The
designers of Java believed in the importance of networking and
designed the Java platform to be network-centric.
Other features that are posed as key benefits are Internationalization,
Performance and programmer efficiency [Flanagan, 2002].
Java is a language that can be used to build robust software:
•
Java is type-safe, meaning that programs are prevented from
accessing objects in inappropriate ways. All code and data is
associated with a type, all objects have a associated type and only
operations defined by the associated type can be performed on an
object. Type safety eliminates an entire category of errors in C and
C++ programs stemming from invalid casts, bad pointer arithmetic and
even malicious code.
•
Java also provides automatic memory management in the form of a
high-performance tracing generational garbage collector. This frees
programmers from performing manual memory management or
reference counting, and eliminates an entire category of errors such as
dangling pointers, memory leaks, and circular references.
•
Java also includes features that promote robustness such as for
example detection of attempts to use uninitialized variables.
17
7 Introducing C# and the .NET Framework
7.1 The History of .NET and C#
Reports of a new language from Microsoft first started Surfacing in 1998. At
that time, the language was called COOL, and was said to be very similar to
Java.
In June 2000, Microsoft released the specifications for a new language called
C# (pronounced “see-sharp”). This was rapidly followed by the release of a
preview version of the .NET Framework SDK (which included a C# compiler)
at the July 2000 Professional Developer’s Conference (PDC), in Orlando
Florida.
The new language was designed by Anders Hejlsberg (creator of Turbo
Pascal and architect of Delphi), Scott Wiltamuth, and Peter Golde. With C#,
they focused on what was right about existing languages and adding
improvements to make something better [Jones, 2001]. Described in the C#
Language specification as a “…simple, modern, object-oriented, and type safe
programming language derived from C and C++” [ECMA(a), 2002], C# bears
many syntactic similarities to C++ and Java [Drayton et al., 2003].
From July 2000 to January 2002, the .NET Framework underwent an
extensive public beta that allowed developers to “try out” the programming
environment. This allowed Microsoft to both solicit and react to developer
community feedback before finalizing the new platform.
From the earliest public previews, core specifications detailing
the C#
language, the classes in the Framework class library (FCL), and the inner
workings of the Common Language Runtime (CLR) have been freely
available.
In November 2000, began an intense standardization process by submitting
the specifications for the C# language, a subset of the FCL, and the runtime
environment to ECMA for standardization. Organizations participating in the
effort included Microsoft, HP, Intel, IBM, Fujitsu Software, ISE, Plum Hall,
Monash University and others. The work was performed under the auspices
of ECMA Technical committee TC39.
18
After more then a year, the task groups completed their standardization work
and presented the specifications to the ECMA General Assembly. In
December 2001 the general Assembly ratified the C# and Common Language
Interface (CLI) specifications, assigning them the ECMA standard numbers of
ECMA-334 (C#) [ECMA(a), 2002] and ECMA-335 (the CLI) [ECMA(b), 2002].
In late December, 2001, ECMA submitted the standards to the International
Organization for Standardization (ISO) via the Fast-Track process, and in
April 2003, ISO ratified the standards as ISO/IEC 23270 (C#) [ISO/IEC(a),
2003] and ISO/IEC 23271 (CLI) [ISO/IEC(b), 2003] giving C# and the CLI
bona-fide international standard status (see bibliography for the web links of
these standards).
Of course, for the standard to have an impact there must be implementations.
In addition to the commercial .NET Framework, Microsoft itself has two other
CLI implementations: the Shared Source CLI (SSCLI, but formerly known
under the code name Rotor) and the .NET Compact Framework. The first is a
working implementation of the CLI and C# standards that builds and runs on
Windows XP, FreeBSD and Mac OS X (web link: http://www.sscli.net) . The
latter, now available with Visual Studio.NET 2003, is an implementation of the
CLI designed to target resource-constrained devices, and is available for
Pocket PC 2000+ and Windows CE 4.1+ operating systems [Drayton et al.,
2003].
However, Microsoft’s implementations are not the only ones available. Other
CLI implementations include the Mono project and dotGNU.
•
The Mono project (http://www.go-mono.com and http://www.monoproject.com), started by the Ximian Corporation, is aiming to provide an
implementation of not only the CLI platform and the C# compiler, but
also a larger set of classes selected from Microsoft’s .NET Framework
FCL. In addition to the internal resources, Ximian has committed to the
project, the Mono project has also attracted attention from the broader
open source community, and appears to be gathering steam [Drayton
et al., 2003]. But Mono tries to be much more. Apart from a compiler for
the C# language, an ECMA-compatible runtime engine (the Common
19
Language Runtime, or CLR), and class libraries (including ADO.NET
and ASP.NET), Mono also has its own and third party class libraries.
Gtk#, a set of .NET bindings for the gtk+ toolkit and assorted GNOME
libraries. This library allows you to build fully native Gnome application
using Mono and includes support for user interfaces built with the
Glade interface builder. Furthermore, Mono's runtime can be
embedded into applications for simplified packaging and shipping. In
addition, the Mono project offers an IDE, debugger, and documentation
browser [Mono Project, 2004].
•
While
not
as
high-profile
as
Mono,
the
dotGNU
project
(http://www.dotgnu.org) has also been making headway, and includes
some interesting and unique concepts. The core of dotGNU is
Portable.NET, which was originally developed by Rhys Wheaterly
before merging his project with dotGNU in August 2000. There are
unique aspects to the dotGNU project, including the fact that it was
originally designed around a CIL (Common Intermediate Language)
interpreter rather then a JIT (Just-In-Time) compiler, and the
developers’ plan to support directly executing Java binaries [Drayton et
al., 2003].
7.2 The .NET Framework
The Microsoft .NET Framework consists of two important elements: a runtime
environment called Common Language Runtime (CLR), and a class library
called the Framework Class Library (FCL). The FCL is build on top of the CLR
and provides services needed by modern applications (figure 2).
20
Fig 2 : the .NET Framework
While applications targeting the .NET Framework interact directly with the
FCL, the CLR serves as the underlying engine.
The CLR is a modern runtime environment that manages the execution of
user code, providing services such as JIT (just-in-time) compilation, memory
management, exception management, debugging and profiling support, and
integrated security and permission management.
Ultimately, the CLR exists to safely execute managed code, regardless of the
source language. In order to provide cross-language integration (one of the
goals of the .NET Framework), the CLR needs intimate knowledge of the
managed code that it is executing. To meet this requirement, the CLR defines
a shared type system called the Common Type System (CTS). The CTS
defines the rules by which all types are declared, defined and managed,
regardless of the source language. The CTS is designed to be rich and
flexible enough to support a wide variety of source languages, and is the
basis for cross-language integration, type safety, and managed execution
services.
Since not all languages support the exact same set of constructs, this can be
a barrier to cross-language integration. The solution to this problem is the
21
Common Language Specification (CLS). The CLS defines the reasonable
subset of the CTS that should be sufficient to support cross-language
integration, and specifically excludes problem areas such as unsigned
integers, operator overloading and more.
Each managed language decides how much of the CTS to support.
Languages that consume any CLS-compliant type are known as CLS
Consumers. Languages which can extend any existing CLS-compliant type
are known as CLS Extenders. The C# language is both a CLS Consumer and
a CLS Extender, and supports all of the important CTS features.
The combination of the rich and flexible CTS and the widely supported CLS
has led to many languages being adapted to the target .NET platform. By
2003, Microsoft was offering compilers for six managed languages (C#,
VB.NET, Jscript, Managed extensions for C++, Microsoft IL and J#), and a
host of other commercial vendors and academics were offering managed
versions of languages such as COBOL, Eiffel, Haskell, Mercury, Mondrian,
Oberon, Forth, Scheme, Smalltalk, APL, several flavors of Pascal and more
(Figure 2) [Drayton et al., 2003].
7.3 The C# programming language
The C# language was designed from the ground up around the assumption
that modern systems are build using components. Consequently, C# provides
direct language support for common components constructs such as
properties, methods, and events. C# also allows developers to directly
annotate and extend a component’s type information to provide deployment,
design, or runtime support, integrate component versioning directly into the
programming model, and integrate XML-based documentation directly into C#
source files. C# also discards the C++ and Component object model (COM)
approach of spreading source artifacts across header files, implementation
files, and type libraries in favor of a much simpler source organization and
component reuse model.
In addition to deeply integrated support for building component-based
systems, C# is also a fully capable object-oriented language, supporting all
22
the common concepts and abstractions that exist in languages such as C++
and Java.
In addition, C# incorporates features from C++ such as operator overloading,
user-defined conversions, true rectangular arrays, and pass-by-reference
semantics that are currently missing in Java.
The syntax of C# was selected to be familiar to C, C++ and Java developers,
making it easier to learn C# and aiding source code porting.
Unlike most programming languages, C# has no runtime library of its own.
Instead, C# relies on the vast class library in the .NET Framework for all its
needs, including console I/O, network and file handling, collection data
structures, and many other facilities.
The C# language strives to balance the need for consistency and efficiency.
Some object-oriented languages (such as Smalltalk) take the viewpoint that
“everything is an object”. This approach has the advantage that instances of
primitive types (such as integers) are first-class objects. However, it has the
disadvantage of being very inefficient. To avoid this overhead, other
languages (such as Java) choose to separate the type system into primitives
and everything else, leading to less overhead, but also a schism between
primitive and user defined types.
C# balances this two conflicting viewpoints by presenting a unified type
system in which all types (including the primitive types) are derived from a
common
base
type,
while
simultaneously
allowing
for
performance
optimizations that allow primitive types to be treated as raw memory, with
minimal overhead and increased efficiency.
The C# language (in concert with the .NET Framework) promotes software
robustness in a number of different ways [Drayton et al., 2003]:
•
C# is a type-safe language. All code and data is associated with a type,
all objects have a associated type and only operations defined by the
associated type can be performed on an object. Type safety eliminates
an entire category of errors in C and C++ programs stemming from
invalid casts, bad pointer arithmetic and even malicious code.
23
•
C# also provides automatic memory management in the form of a highperformance tracing generational garbage collector. This frees
programmers from performing manual memory management or
reference counting, and eliminates an entire category of errors such as
dangling pointers, memory leaks, and circular references.
•
A language needs to have a consistent mechanism for detecting errors.
In the past these mechanisms were often very complex. The .NET
Framework eliminates this complexity by standardizing on a single
exception-handling mechanism that is used throughout the framework,
and exposed in all .NET languages including C#.
•
The C# design also includes multiple features that promote robustness
such as language-level support for independently versioning base
classes, detection of attempts to use uninitialized variables, array
bounds checking, and support for checked arithmetic.
24
8 A first small comparison based on known facts
When we keep the previous two chapters in mind, one might have already
noted a few differences and similarities between the two platforms/languages.
Table 1 shows a list with some of the similarities and differences between
Java and .NET. We only list a few of them. Some of the features, like security
are relevant to this thesis and that is why they will be discussed more
thoroughly.
Table 1: Some of the similarities and differences between C#/.NET and Java..
Java
.NET
Syntax
Similar to C, C++
Similar to C, C++, Java
Virtual machine
JVM
CLR
Portable code
Byte code
IL
JIT Compiling
Yes
Yes
Garbage collection
Yes
Yes
Core libraries
JCL
BCL
GUI libraries
AWT, Swing (,SWT)
Windows.Forms
Security
Good
Good
High
High
Yes
No
No
Yes
No
Yes
Importance of
Networking
Portability
Cross-language
Integration
Standardized
(EMCA, ISO/IEC)
8.1 Syntax
As already stated before, the Syntax of both languages is very similar [Eckel,
2002; Drayton, 2003]. They are designed to remove the complexity of C++ in
a way that developers who are acquainted with C++ can easily learn the new
language. Some of the syntactic similarities and differences can be found in
Obasanjo [2001] and Albahari [2000].
25
8.2 Virtual machines and portable code
The comparison between [C#/IL Code/CLR] and [Java/Byte-Code/JVM] is an
inevitable and valid comparison to make [Albahari, 2000]. I will try to do this
by shortly explaining how the two runtime architectures, that execute code,
work and explain some of the differences.
Java source code compiles into machine-independent byte code, which the
JVM interprets at runtime. With that in mind, the particular installed JVM
proves crucial to performance and scalability. Sun supplies its HotSpot VM
with Java while other JVM implementations exist. As its name suggests,
HotSpot looks for repeatedly executed code sections, then intensively
optimizes them. HotSpot also supplies the standard configurable security
model for code loading and execution. As a final feature, the JVMs leverage
their host machines' strengths. For example, JVMs optimized for Solaris will
take advantage of that operating system's special features, such as, for
example, thread management.
The CLR environment executes .Net's Microsoft Intermediate Language
(MSIL, or just IL) code. Like the JVM, the CLR also offers support services,
such as code verification, memory management through garbage collection,
and code security. The JVM and the CLR may look like identical twins, but
they're more like cousins:
•
First, Microsoft designed the CLR to support multiple languages,
whereas the JVM supports only one - Java. Microsoft currently
provides CLR-compliant versions of Visual Basic, C#, C++, JScript,
and even Java (§ 7.2). Other vendors are also working to support
additional languages, such as COBOL, FORTRAN, and Perl. It is of
course also theoretically possible that one could develop a second
language for the JVM, next to Java.
•
Second, in .Net, managed code always translates into native machine
code rather than interpreted. The CLR, unlike the JVM, supports
26
compilation from the start. Although all JVMs provide just-in-time (JIT)
compilers or HotSpot today, the JVM was originally designed as an
interpreter.
•
Third, consider .Net's support for application domains. Application
domains resemble processes; they provide the same isolation level
without the overhead that comes from making cross-process calls or
switching between processes, because they can run within a single
process space. That ability to run multiple applications within a single
process dramatically increases server scalability, something not
supported by JVMs [Sheil & Monteiro, 2002].
•
Fourth, while JVM adds virtual method dispatch, interfaces and things
that are in JAVA, it doesn't support pointers. CLR has both [Ikram,
2003]. By saying that Java is not supporting pointers, we really mean
that, although core C# is like Java in that there is no access to a
pointer type that is analogous to pointer types in C and C++, it is
possible though to have pointer types if the C# code is executing in an
unmanaged context. When C# code is executing in an unsafe context,
a lot of runtime checking is disabled which means that the program
must have full trust on the machine it is running on. Certain situations
call for the use of unsafe code such as when interfacing with the
underlying operating system, during interactions with COM objects that
take structures that contain pointers, when accessing a memorymapped device or in situations where performance is critical. Java
does not support the use of unsafe code in which you can manipulate
pointers [Obasanjo, 2001]. It is possible though to do this in Java by
using the Java native interface (JNI).
8.3 Portability
By discussing the JVM/CLR we inevitably touch the concepts of Language
interoperability (as discussed above). Another important feature that comes to
mind in this discussion is portability. Java offers complete cross-platform
portability. If a JDK exists for your target platform, then Java can run on it. The
ability to support Windows and mainframes and everything in-between
27
represents a big Java attraction. The CLR includes a JIT compiler that
translates IL into machine code running on target platforms. Currently, .Net
only supports the Windows platform, but in theory, other platforms could have
their own JIT compilers [Sheil & Monteiro, 2002]. The possible future proof of
this will be Mono, which is designed to work on Linux, Windows and Mac OS
X (§ 7.1).
8.4 Standardization
Another difference between the two languages, that may, or may not be
important is standardization. While C# is standardized by EMCA (ECMA-334))
[ECMA(a), 2002] and ISO/IEC (ISO/IEC 23270) [ISO/IEC(a), 2003], Java isn’t.
Anyone can propose a JSR for a new platform extension, and the Java
Community Process (JCP) keeps Java technology open with input from IBM,
HP, BEA Systems, and many other participants. Adding to the language itself,
however, proves nearly impossible. Sun is conservative about introducing
changes to the Java language. Microsoft has long been criticized for tightly
controlling its technologies. However, by standardizing the C# language and
the CLI, the company took a huge step forward, allowing others to participate
in their evolution [Sheil & Monteiro, 2002]. Customers value a product more
highly when it is compatible with other products. This gives consumers an
interest in the widest possible standardization.
On the other hand,
standardization prevents diversity, and so might fail to satisfy differing
consumer tastes.
So, for consumers, there are advantages and
disadvantages from standardization [MacCarthy, 2004]. Considering these
arguments, it is not easy to decide whether standardization is a positive or a
negative feature.
8.5 Security
A last issue I want to address in this chapter is Security. I want to discuss this
feature because both platforms have spent quite a lot of effort in providing a
solid, safe security system and because it is an important part of my thesis (§
11). In the past, Microsoft has had a bit of a bad reputation considering
security. In the past years and also recently, with the appearance of the
28
second service pack for Windows XP, Microsoft has tried to get rid of this bad
reputation. A comparative study of security features of Java v1.4.2/J2EE v1.4
(beta2) and .NET v1.1 platforms has been conducted by Pilipchuk. The
following
areas
Containment
were
considered:
[Philipchuk,
2003(a)],
Security
Configuration
Cryptography
and
and
Code
Communication
[Philipchuk, 2003(b)], Code Protection and Code Access Security, or CAS,
[Philipchuk, 2004(a)], and Authentication and User Access Security, or UAS,
[Philipchuk, 2004(b)]. Some of the conclusions of this articles can be
interpreted like this:
•
.NET’s Code Access Security (CAS) is a much better system than
Java's equivalent system, although Java is more easily extensible
[Philipchuk, 2004(a)].
•
Java's
X509
certificate
class
is
much
better
than
.NET's
X509Certificate (which will be rectified with the upcoming Whidbey1
X509CertificateEx class). This is because Java provides a solid API for
dealing with certificates. .NET programmers have to turn to
unmanaged CryptoAPI functions to access certificates, unless they
use Web service extentions, which add a lot of useful functionality.
[Philipchuk, 2003(c)]. Overall the two cryptography systems are about
equal, with Java having a slightly more complex class hierarchy due to
their initial structuring around United States export restrictions.
Philipchuk also writes that .NET is much better for security when it
comes to web services, since Java doesn't even provide a solution
there. Here, Java developers would have to turn to independent
vendors for the desired features [Philipchuk, 2003(b)].
The overall conclusion is that .NET and Java both earn pretty high marks on
the security comparison, which should not be too surprising, considering the
long history of Java in the enterprise and the amount of effort that Microsoft is
1
Whitbey is the codename of the next .NET Framework release due in 2005, the previous
version (v1.1) being called Everett. Whidbey contains many features that were designed fromthe-ground-up to make designing, developing and deploying secure software a simpler and
more robust process, and leveraging these features can significantly shorten the development
time of .NET applications [Wienholt, 2004]. Check Microsoft [2004] for more improvements of
Whitbey.
29
putting into making .NET a premier Windows development platform.
Traditionally (and .NET is not an exception), Microsoft products have done
best in the closed, homogeneous environment of all-Windows networks, while
enterprise Java performs quite well in heterogeneous environments. If we
consider an all-Microsoft network, it allows system integration and utilization
of .NET's security features to their fullest potential. In case of a mixed
environment, Java's platform-independent security features may be more
useful than those of .NET. Also, when issues like communication security and
authentication across networks start coming into play, Java seems to be a
good choice [Philipchuk, 2004(b)].
As stated above, the two cryptography systems are about equal [Philipchuk,
2003(b)]. This may prove to be an interesting starting point to start measuring
the performance of the encryption. This information can then be used to
compare both languages and platforms. This is done in chapter 11.
30
9 The Applications
9.1 The P2P Application
Both the Java version as the C# version of the P2P application are as
identical as possible. They are meant to be used on a local network only. It
are applications that in the first place send broadcasts every thirty seconds.
Broadcasts are send to a multicast group using the User Datagram Protocol
(UDP), and are transferred to every user that has joined that multicast group.
Those broadcasts contain the nickname, the IP and the status of the user.
The received data is then stored in a contact list, containing every online user
on the network that uses the application.
Both applications have the ability to function as a client or as a server but no
external server is needed. They can be considered as adequate Peer-to-Peer
(P2P) applications (See § 10 for a description). A user is able to send
messages or files to an online contact using the Transmission Control
Protocol (TCP). Both the messages and the files are encrypted and
decrypted, using the tripleDES algorithm (see § 11.1.2 for a description). The
two applications have also been made compatible, meaning you can send
files from a Java client to a C# client and the other way around.
These two applications will be used for the P2P performance experiment
(§10.2).
C# is capable of reading an entire file and passing this file to the socket, using
the TcpClient class. The TcpClient class builds upon the Socket class to
provide TCP services at a higher level of abstraction. TcpClient provides
simple methods for connecting, sending, and receiving data over a network
[MSDN, 2004]. When using this class, the .NET framework will take care of
the file and make sure the programmer doesn’t have to worry about buffering
the file. Java isn’t able to send files bigger then 65 kb (which is the size of one
TCP packet) through a socket unless they are being buffered. To assure
interoperability, the files that are being send and received by C# also need to
be buffered. To achieve this correctly for larger files, a delay of 19
milliseconds between each packet (containing 5120 bytes) had to be added.
This delay has also been added to the Java version.
31
Apart from the two identical applications, a third application was created. This
application is an alternative C# version that doesn’t buffer the files and is
capable of sending larger files using the TCP class, as described above. It
might be interesting to see whether sending files by using this application is
faster then sending them buffered.
9.2 The applications for encryption
Four applications have been made. Two for each language. The first
application is capable of encrypting and decrypting a desired file, using the
TripleDES algorithm. The other application is capable of doing the same thing
but by using the AES or Rijndael algorithm in stead of the TripleDES algorithm
(see § 11.1.3 for a description).
These four applications will be used for the symmetric encryption performance
experiment (§11.2).
32
10 Using a P2P messenger for performance
measurements.
10.1 What is peer-to-peer?
10.1.1
An overview
Put simply, peer-to-peer (P2P) computing is the sharing of computer
resources and services by direct exchange between systems. P2P systems
are built up of nodes (typically a computer) that are networked together in
some fashion. Communication that passes between these nodes can, for
example, involve the transference of data or the relaying of commands from a
control node to a slave node [Lancaster, 2001a]. This may surprisingly seem
to contradict the P2P paradigm that assumes that all peers are equal (in
contradiction with the client – server paradigm). In fact they all are, but when a
peer requests services from another peer, a temporary client – server relation
will be established in which one peer will act as the control node and the other
as the slave node. When the requested services are satisfied, this relation
will disappear again, making both peers equal again.
Two core types of architecture exist (fig. 3) [Lancaster, 2001a].
•
Decentralized, where each node within the network is regarded as an
equal and no control nodes exists (fig 3a)
•
Semi-centralized, where there exists at least one control node that
performs an authoritative role within the network (fig 3b).
Fig 3a: Examples of decentralized P2P networks: (from left to right): direct communication,
structured indirect communication, unstructured indirect communication.
33
Fig 3b: Examples of semi-centralized P2P networks: (from left to right): single centralized
index server, computational model (no autonomy), computational model (with autonomy),
multiple server model.
A more detailed description of these models can be obtained in Lancaster
[2001a]. A comparison between different P2P architectures can be found in
Melville et al. [2003].
In recent years, P2P has gained a lot of attention, be it positive or negative.
Anyhow, the use of P2P software has increased dramatically. As the power of
home computers and Internet access speeds increase, Hughes et al. [2004]
envisage that an increasingly diverse set of applications will seek to make use
of the growing pool of resources available around the edge of the network.
There are many computing and scientific problems that can be aided by the
correct application of P2P technology. The Search for Extraterrestrial
Intelligence (SETI) project for example, utilizes spare CPU cycles on client's
machines to analyze vast amounts of radio telescope data for evidence of
extraterrestrial life. Another way in which P2P computing may aid us, is in the
searching and indexing of web content, thus relieving the work put on web
spiders. Finally, P2P technology can help support communication and
collaboration between users. The proliferation of Instant Messenger
applications such as ICQ, AIM and MSN Messenger illustrates this fact.
This stresses the importance of P2P, and shows why it is interesting to
compare the performance of the Java and .NET platform, which both offer
support for P2P development, regarding this concept.
34
10.1.2
Java vs. .NET
For the development of P2P applications, both platforms that are discussed
throughout this thesis, Java and .NET, offer a possible solution. I will discuss
them briefly.
The first technology is JXTA, short for juxtapose - meaning side by side (http://www.jxta.org), an open source API, containing a generalized set of P2P
protocols that is produced by Sun Microsystems Inc. The intention of these
protocols is to allow any device that is available on the network to
communicate and collaborate as peers. It is important to note that JXTA is
build using Java primitives (these can be compared to the .NET primitives
discussed below).
One of the main objectives of JXTA is to provide a platform that supports the
development of P2P systems and provides much of the basic networking
functionality that is required in such development. In particular JXTA aims to
achieve:
•
Interoperability – JXTA is designed to enable peers to easily locate
each other, communicate to each other and offer services to each
other and to achieve this transparently across different networks and
communities.
•
Platform independence – JXTA is designed to operate independently of
programming languages (such as C or Java), system platforms (such
as Microsoft Windows and UNIX), and networking platforms (such as
TCP/IP or Bluetooth)
•
Ubiquity – JXTA is designed to be implemented on any device ‘with a
digital heart beat’. This can include sensors, consumer electronics,
PDA’s, network routers, desktop computers and storage systems.
JXTA has some advantages and disadvantages. Some of the disadvantages
described in Lancaster [2001b] are: JXTA being open source has a downside:
Although the JXTA project is managed, due to the openness of its
development enforcing strict control is difficult. The very nature of JXTA
means that its development has to be spread over many machines. These
35
machines can be located all over the world, be operated by individuals or
companies, and be operational at irregular times of the day. These factors can
have a dramatic effect on the systems reliability. For example, by a peer
removing itself from the JXTA network any other peers who used it as a
connection point to the network will suddenly find themselves isolated from
the network (partitioned) [Lancaster, 2001b].
At the time Lancaster [2001b] was written, security was also very simplistic.
This was acknowledged by the developers but Sun [2002a] believes that
JXTA technology can easily adopt a security model that relies on existing,
trusted technologies, with no compromises from the strong security that users
and enterprises have come to expect from traditional computing approaches.
Such an approach is made practical as a consequence of three choices made
by the Project JXTA team: the adoption of Transport Layer Security (TLS), an
industry protocol for the secure transport of information; the exploitation of the
end-to-end transport independence of JXTA protocols; and the use of
X509.V3 digital certificates in such a way that centralized certificate
authorities are not mandatory, and at the same time not excluded.
Some of the advantages of JXTA are its platform independence, the fact that
it provides a specific support for P2P development and the fact that it’s an
ongoing project with a large development base.
The second technology is .NET, developed by Microsoft. It is important to
stress that .NET doesn’t provide direct support for P2P. Several elements of
the .NET API can be used for P2P application programming though. In
particular, the .NET API has class namespaces that can be used for P2P
development [Lancaster, 2001b]:
•
System.Net namespace: This namespace has a set of classes for
integrating Internet protocols into an application. It uses a layered
approach so varying levels of control can be added to an application
from pure socket control to general request/response actions.
•
System.Web.Services namespace: Here web services can be created
and exposed to the outside world. A web service in the .NET
36
framework is a programmable application logic, that can be accessed
with Simple Object Access Protocol (SOAP) messages. Peers
connecting to the service only need to know how to send and receive
SOAP messages. SOAP is also available in Java, although not
included
in
the
J2SE.
You
can
find
Apache
SOAP
on
http://ws.apache.org/soap/.
•
System.Windows.Forms namespace: System.Windows.Forms is the
framework for building GUI components that can be added to a P2P
application.
The
Java
GUI
namespaces
are
java.awt.*
and
javax.swing.*. An alternative to these last two is SWT, a software
component that delivers native widget functionality for the Eclipse
platform in an operating system independent manner [Northover,
2001].
The Microsoft .NET framework does not have any specific peer-to-peer
capabilities such as the JXTA API. It is not designed simply for building P2P
networks, however P2P applications and their network support can be built
with the .NET framework (although this will require additional work from the
developers). Much like JXTA and the Java layers underneath it .NET has
been designed to run on any platform that has a “Common Language
Runtime” and it’s associated JIT compiler. This leaves developers open to
write applications in the language of their choice, for the platform of their
choice, and still allow interoperability with other platforms.
Security is strongly considered by Microsoft, and this can be seen with the
.NET framework and its support for user centricity. This certainly seems to be
an evolution of Microsoft’s passport service [Lancaster, 2001b].
It might be interesting to note that Microsoft is working on a project
(codename HailStorm). Essentially, HailStorm is a Web-based service for
storing and retrieving information. It isn’t P2P for .NET in se, but it tries to
implement P2P features like decentralization. This by shifting from a machinecentric application model to a distributed computing model to shift the central
unit away from the computer and towards the user. In a distributed model, it is
the user and not the hardware that needs to be validated, so user
37
authentication becomes the core attribute -- not "Is this software licensed to
run on this machine?" but "Is this software licensed to run for this user?" To
accomplish this they require a system that first validates users, and then
maintains a list of attributes in order to determine what they are and are not
allowed to do within the system. This may appeal to developers who want to
offer Web services without rethinking identity or authentication from the
ground up (one of the biggest hurdles to widespread use of Sun's JXTA)
[Shirky, 2001].
More information on developing a P2P application in .NET can be found in
Olson [2001].
10.2 How do we measure performance?
The Java and the C# application are described in § 9.1. Performance of the
sending and receiving of files, using TCP, will be measured using a
StopWatch class. This StopWatch class, as described in appendix B for both
languages, acts like a real life stop watch and is capable to return the time
needed to perform an action. The same performance tests will be conducted
on the sending an receiving of multicast massages and on the extra C#
application that doesn’t need file buffering (see §9.1).
For the performance test that measures the time it takes to send and receive
a file, 5 dummy files were created with a file size of 1 Kb, 10 Kb, 100 Kb, 1 Mb
and 10 Mb. The time returned by the StopWatch class is in milliseconds. Files
were send and received in-between the same applications (for example from
Java 1.4.2 version to a Java 1.4.2 version) and in-between different versions
(for example from a C# version to a Java 1.5 beta version). This to see
whether the interoperability had an influence on the performance.
Because the resulting times from the same test do tend to differ a little, each
test was done five times. The fastest result out of five was recorded. Each
experiment has been carried out on the same system. This is a Pentium IV
2.4 GHz with 256 Mb RAM, running Windows XP Professional edition.
38
Due to the recent appearance of the Java 1.5 beta JRE (and JDK), the Java
application has been compiled and tested both in Java 1.4.2 as well as in
Java 1.5 beta. This to see if there might be a difference in performance
between the two versions.
10.3 Results of the P2P performance test
The sending and receiving performance of multicast messages is equal for
both languages. Sending a UDP message happens instantly (0 milliseconds).
The same is true for receiving the packets (30000 milliseconds, which is
exactly the interval at which broadcasts are send).
In table 2, figure 4 and figure 5, you see the results of the file transfer
performance of the applications for sending a file.
Table 2: The results of the file transfer performance test regarding the sending of a file. Times
are in milliseconds. The first column denotes two applications The first one is the application
that has sent the message, the second one is the one that received the message. PureC# is
the C# application without the file buffering (see §9.1).
C# Æ C#
C# Æ Java 1.5 beta
Java 1.5 beta Æ C#
Java 1.5 beta Æ Java 1.5 beta
Java 1.4.2Æ Java 1.4.2
PureC#Æ PureC#
1Kb
16
15
15
15
16
0
10Kb
47
31
31
31
31
0
100Kb
406
406
391
391
390
15
1Mb
4109
4015
3828
3828
3844
109
10Mb
40188
40078
38296
38172
38172
1070
There doesn’t seem to be a real difference in performance between the Java
1.4.2 and the Java 1.5 beta applications. C# seems to be a little slower then
the two Java applications. Certainly when considering the larger files where
we can see a difference of two seconds.
The C# version without the packet buffering, PureC#, is a lot faster then the
other versions.
39
File Transfer Performance: Sending
45000
40000
Time in Milliseconds
35000
C# -> C#
30000
C# -> Java 1.5 beta
25000
Java 1.5 beta -> C#
20000
Java 1.5 beta -> Java 1.5 beta
Java 1.4.2 -> Java 1.4.2
15000
PureC# -> PureC#
10000
5000
0
1Kb
10Kb
100Kb
1Mb
10Mb
File Size
Fig. 4: The results of the file transfer performance of the applications for sending a file,
including the results for the 10 Mb file
File Transfer Performance: Sending
5000
4500
Time in Milliseconds
4000
3500
C# -> C#
C# -> Java 1.5 beta
3000
Java 1.5 beta -> C#
2500
Java 1.5 beta -> Java 1.5 beta
2000
Java 1.4.2 -> Java 1.4.2
1500
PureC# -> PureC#
1000
500
0
1Kb
10Kb
100Kb
1Mb
File Size
Fig. 5: The results of the file transfer performance of the applications for sending a file,
excluding the results for the 10 Mb file
In table 3, figure 6 and figure 7, you see the results of the file transfer
performance of the applications for receiving a file
40
Table 3: The results of the file transfer performance test regarding the receiving of a file.
Times are in milliseconds. The first column denotes two applications The first one is the
application that has sent the message, the second one is the one that received the message.
PureC# is the C# application without the file buffering (see §9.1).
C# Æ C#
C# Æ Java 1.5 beta
Java 1.5 beta Æ C#
Java 1.5 beta Æ Java 1.5 beta
Java 1.4.2 Æ Java 1.4.2
PureC# Æ PureC#
1Kb
15
31
15
16
46
16
10Kb
31
31
15
31
46
32
100Kb
375
390
344
359
360
328
1Mb
3891
3906
3890
3890
3921
2750
10Mb
39078
39125
39171
39140
39125
27125
There doesn’t seem to be a difference in performance between the C#, the
Java 1.4.2 and the Java 1.5 beta application. All seem to be about equally
fast. The C# version without the packet buffering, Pure C# receives a 10 Mb
file about twelve seconds faster then the other applications.
File Transfer Performance: Receiving
45000
40000
Time in Milliseconds
35000
C# -> C#
30000
C# -> Java 1.5 beta
25000
Java 1.5 beta -> C#
Java 1.5 beta -> Java 1.5 beta
20000
Java 1.4.2 -> Java 1.4.2
15000
PureC# -> PureC#
10000
5000
0
1Kb
10Kb
100Kb
1Mb
10Mb
File Size
Fig. 6: The results of the file transfer performance of the applications for sending a file,
including the results for the 10 Mb file
41
File Transfer Performance: Receiving
5000
4500
Time in Milliseconds
4000
3500
C# -> C#
3000
C# -> Java 1.5 beta
Java 1.5 beta -> C#
2500
Java 1.5 beta -> Java 1.5 beta
2000
Java 1.4.2 -> Java 1.4.2
1500
PureC# -> PureC#
1000
500
0
1Kb
10Kb
100Kb
1Mb
File Size
Fig. 7: The results of the file transfer performance of the applications for sending a file,
including the results for the 10 Mb file
10.4 Discussion of the results
When we compare the two Java versions, being 1.4.2 and 1.5 beta, we don’t
see much of a difference in performance. Java 1.5 beta doesn’t seem to be
more performant then Java 1.4.2, at least, for sending and receiving files over
TCP that is.
Sending and receiving files happens at about the same speed. The small
differences in the data can be explained as noise in the data. C# seems to be
a bit slower in receiving files then the two Java versions. It is clear though
that, by looking at the receiving of files in the non-buffered C# version
(PureC#), C# can be made a lot faster when the TCP packets are being
handled by the .NET Framework, by using the TcpClient class, instead of
programmatically. It is possible that the buffered C# version is slower because
of the fact that each packet is handled twice. Once by the .NET Framework
and once by the program (which reads all incoming data into packets of 5120
bytes), reducing the C# performance.
42
The performance of sending files by the PureC# application may seem
striking. It is important to note what is written in paragraph 9.2 though. To
achieve the sending of larger files correctly in C#, a delay of 19 milliseconds
between each packet (containing 5120 bytes) had to be added. This delay
has also been added to the Java version. Considering the fact that a 10 Mb
file consists out of 1954 packets of 5120 bytes, this means you have a total
delay of 19 milliseconds * 1954 packets = 37126 milliseconds for a 10 Mb file,
which is close to the actual time measured in the other applications.
The existence of the TcpClient and TcpListener classes in C# seem to make it
easier for the programmer by letting all the TCP packet handling being done
by the .Net Framework rather then by the program.
Performing a statistical test on the results would be an ideal tool to backup
this conclusions. By means of a t-test or an ANOVA (analysis of variance), a
more solid conclusion could be drawn from this result. This might be an
interesting remark for future performance research.
43
11 Using symmetric encryption for performance
measurements.
11.1 What is symmetric encryption?
11.1.1
An overview
Cryptography (from Greek kryptós, "hidden", and gráphein, "to write") is,
traditionally, the study of ways to convert information from its normal,
comprehensible form into an obscured guise, unreadable without special
knowledge [Wikipedia, 2004].
These days, a lot of communication happens across the internet, it is
important that you are able to send messages and files knowing that
unauthorized people aren’t able to read them.
A message is called plaintext (it is sometimes also called cleartext). Plaintext
can be stream of bits, a text file,… The process of disguising a message in
such as to hide its content is called encryption (or enciphering). An encrypted
message is called ciphertext. The process of turning ciphertext back into the
original plaintext is called decryption (or deciphering) [Schneier, 1996]. This
Process is shown in figure 8.
Ciphertext
Plaintext
Encryption
Original
Plaintext
Decryption
Fig 8: The process of encryption and decryption.
There are two important kinds of encryption algorithms: symmetric algorithms
(also known as conventional algorithms) or asymmetric algorithms (also
known as public-key algorithms). I will only discuss the first type for it is the
one that was used in this thesis.
44
Symmetric algorithms are algorithms of which the encryption key can be
calculated from the decryption key and vice versa. In most symmetric
algorithms the encryption and decryption key are one and the same. The
algorithms require that the sender and the receiver agree on a key before they
can start to communicate securely. The security of a symmetric algorithm
rests in the key: revealing the key means that anyone could encrypt or decrypt
the messages. As long as the communication needs to be secret, the key
needs to be secret. This is one of the downsides of symmetric encryption and
this problem is addressed by asymmetric algorithms that introduce a “public”
and a “private” key.
Symmetric algorithms can be divided into two categories. Some operate on
the plaintext a single bit (or sometimes byte) at a time. These are called
stream algorithms or stream ciphers. Others operate on the plaintext in
groups of bits. These groups are called blocks and the algorithms are called
block algorithms or block ciphers (figure 9) [Schneier, 1996]. The two
algorithms used and described in this thesis, Triple-DES (§ 11.1.2) and AES
(§ 11.1.3), both are block ciphers.
Fig. 9: Encryption and decryption using a block cipher [Wikipedia, 2004a].
Block sizes are typically 64 or 128 bits, though some ciphers have a variable
block size. To encrypt a message that is longer than the block size, one of the
modes of operation must be used. I will discuss the two most important ones.
45
The simplest of the encryption modes is the electronic codebook (ECB) mode,
in which the message is split into blocks and each is encrypted separately.
The disadvantage of this method is that identical plaintext blocks are
encrypted into identical ciphertext blocks; it does not hide data patterns. The
advantage is that error propagation is limited to a single block [Wikipedia,
2004].
Cipher block chaining (CBC) uses an Initialization Vector (IV) of a certain
length (while EBC does not require a IV). This is a sort of dummy block to kick
off the process for the first real block, and also provide some randomization
for the process. One of the key characteristics of CBC is that it uses a
chaining mechanism that causes the decryption of a block of ciphertext to
depend on all the preceding ciphertext blocks. As a result, the entire validity of
all preceding blocks is contained in the immediately predecessor (figure 10).
Fig. 10: Encryption and decryption using Cipher Block Chaining (CBC) [Wikipedia, 2004b]
46
A single bit error in a ciphertext block affects the decryption of all subsequent
blocks. Rearrangement of the order of the ciphertext blocks causes decryption
to become corrupted. Identical ciphertext blocks can only result if the same
plaintext block is encrypted using both the same key and initialization vector,
and if the ciphertext block order is not changed. It has the advantage over the
Electronic Code Book mode in that it hides plaintext patterns. Ideally, the
initialization vector should be different for any two messages encrypted with
the same key. Though the initialization vector need not be secret, some
applications may find this desirable. For CBC, reusing an IV leaks some
information [Wikipedia, 2004b].
The importance of encryption and security in modern society keeps on
growing. Most of the means of secure data and code storage and distribution
rely on using cryptographic schemes, such as certificates or encryption keys.
Thus, cryptography mechanisms form a foundation upon which many
important aspects of a solid security system are built, and it is crucial for a
really secure platform to provide adequate support for these services
[Pilipchuk, 2003b]. Both Java and .NET have spend a lot of effort in providing
that good, solid security system to it’s users. In Chapter 8 we concluded that
both encryption systems were about equal. Therefore, a comparison of the
performance of both platforms, and their respective programming languages
Java and C# in this area would be very interesting.
11.1.2
The TripleDES algorithm
The tripleDES algorithm, also known as 3DES, is in fact an improvement of
the Data encryption Standard (DES) algorithm that was created in 1976.
The DES algorithm is considered to be insecure for many applications. This is
mainly due to the 56-bit key size being too small; DES keys have been broken
in less than 24 hours. There are also some analytical results which
demonstrate theoretical weaknesses in the cipher, although they are
infeasible to mount in practice [Wikipedia, 2004c].
TripleDES was developed by Walter Tuchman, the leader of the DES
development team at IBM. It involves applying DES three times with different
47
keys. It has a key length of 168-bits (three 56-bit DES keys). The use of three
steps is essential to prevent meet-in-the-middle attacks. Those are attempts
where the attacker actively tries to make the communication between the
client and the server run through him [Boeynaems, 2004], placing him literally
in the middle. TripleDES is widely regarded as adequately secure for now
although theoretical attacks have been described in Lucks [1998].
One of the main disadvantages of TripleDES lies in the fact that it is quite
slow [Wikipedia, 2004d].
11.1.3
AES or the Rijndael algorithm
The Advanced Encryption Standard (AES) is also known as the Rijndael
algorithm. Rijndael is a block cipher, designed by Johan Daemen and Vincent
Rijmen in 1998 as a candidate algorithm for the AES. Strictly speaking, AES
is not precisely Rijndael, although in practice they are used interchangeably,
as Rijndael supports a larger range of block and key sizes. AES has a fixed
block size of 128 bits and a key size of 128, 192 or 256 bits, whereas Rijndael
can be specified with key and block sizes in any multiple of 32 bits, with a
minimum of 128 bits and a maximum of 256 bits [Wikipedia, 2004].
In Rijndael, both block length and key length can be extended very easily to
multiples of 32 bits. Rijndael can be implemented very efficiently on a wide
range of processors and in hardware [Rijmen, 2004].
In 2003, the National Security Agency (NSA) reviewed all the AES finalists,
including Rijndael, and stated that all of them were secure enough for US
Government non-classified data. In June 2003, the US Government
announced that AES may be used for classified information [CNNS, 2003].
Some cryptographers worry about the security of AES but up to 2004, no
successful attacks against AES have been recognized. Theoretical attempts
have been made by Courtois & Pieprzyk [2002] and by Ferguson et al. [2000].
48
11.2 How do we measure performance?
To measure the performance of the two symmetric encryption algorithms,
TripleDES and AES, the applications described in §9.2 are used. Both
algorithms, as well in C# as in Java, use the CBC mode of operation and are
made to be as identical as possible, based on Gallant [2004].
For this experiment seven dummy files, those being files completely filled with
the character zero, were created with a file size of 1 Kb, 10 Kb, 100 Kb, 1 Mb,
10 Mb, 50 Mb and 100 Mb. Each application puts the complete file in the
system memory, encrypts it and writes it to a file. Then the newly created file
is read, decrypted and written to another file. The performance of both
encryption and decryption is measured using the StopWatch class that is also
used in the P2P performance experiment in §10.2 (see Appendix B). The time
is returned in milliseconds. Because the resulting times do tend to differ a little
each time the same file is encrypted, each experiment is carried out five
times. The fastest time out of five is selected
Each experiment has been carried out on the same system. This is a Pentium
IV 2.4 GHz with 256 Mb RAM, running Windows XP Professional edition.
For the same reasons as described in paragraph 10.2, a Java 1.5 beta
version of each application has also been made. This to measure if there is a
difference in performance between Java 1.4.2 and Java 1.5 beta.
Also important to note is that the maximum JVM memory size had to be
enlarged in order to encrypt/decrypt the 50Mb and 100Mb dummy files and to
avoid a "java.lang.OutOfMemoryError" error. This was done by adding the
parameter -Xmx400M to the batch file, used for starting the JARs. This
parameter changes the maximal JVM memory size to 400Mb. C# had no
difficulties encrypting/decrypting any of the dummy files.
In §11.3, we will describe the results obtained during the symmetric
encryption test. The conclusion and discussion of these results can be found
in chapter 12.
49
11.3 Results of the symmetric encryption test
The results obtained in the symmetric encryption test are displayed in table 4.
Looking at the results, the reader can immediately notice a few things. First of
all, the AES algorithm always encrypts and decrypts a file faster then the
TripleDES algorithm. This is obvious in both Java implementations for the C#
implementation, you only start to see this trend in the larger file sizes.
When we compare the different platforms with each other, it is also clear that
the C# TripleDES implementation is almost twice as fast as both Java
versions, and this for every file size (fig 11 and fig 12). For the AES algorithm,
we have the reverse situation (fig 13 and fig 14) . Here the two Java
implementations are almost twice as fast as the C# implementation, except for
the largest file size (100 Mb) where the C# implementation is the fastest.
When we compare both Java 1.4.2 and Java 1.5 beta, we can see that the
performance of the two implementations of the TripleDES algorithm is about
equal, with an exception in the encryption of the 100Mb file. The same can be
observed for the AES implementations, again with an exception in the 100 Mb
file.
Triple DES benchmark
140000
Java 1.4.2 encrypt
Java 1.4.2 decrypt
Java 1.5 beta encrypt
Time in milliseconds
120000
Java 1.5 beta decrypt
C# encrypt
C# decrypt
100000
80000
60000
40000
20000
0
1Kb
10Kb
100Kb
1Mb
10Mb
50Mb 100Mb
Filesize
Fig 11: The results of the symmetric encryption test for the TripleDES algorithm, including the
100 MB file size.
50
Triple DES benchmark
18000
Java 1.4.2 encrypt
16000
Java 1.4.2 decrypt
Java 1.5 beta encrypt
14000
Java 1.5 beta decrypt
Time in milliseconds
C# encrypt
12000
C# decrypt
10000
8000
6000
4000
2000
0
1Kb
10Kb
100Kb
1Mb
10Mb
50Mb
Filesize
Fig 12: The results of the symmetric encryption test for the TripleDES algorithm, excluding
the 100 MB file size.
AES benchmark
Java 1.4.2 encrypt
120000
Java 1.4.2 decrypt
Java 1.5 beta encrypt
100000
Java 1.5 beta decrypt
Time in milliseconds
C# encrypt
C# decrypt
80000
60000
40000
20000
0
1Kb
10Kb 100Kb
1Mb
10Mb
50Mb 100Mb
Filesize
Fig 13: The results of the symmetric encryption test for the AES algorithm, including the 100
MB file size.
51
Time in milliseconds
AES benchmark
8000
Java 1.4.2 encrypt
Java 1.4.2 decrypt
7000
Java 1.5 beta encrypt
Java 1.5 beta decrypt
6000
C# encrypt
C# decrypt
5000
4000
3000
2000
1000
0
1Kb
10Kb
100Kb
1Mb
10Mb
50Mb
Filesize
Fig 14: The results of the symmetric encryption test for the AES algorithm, excluding the 100
MB file size.
52
Table 4: The results of the symmetric encryption performance test. All recorded times are in milliseconds.
1Kb
Java
1.4.2
Java
1.5beta
C#
10Kb
100Kb
1Mb
10Mb
50Mb
100Mb
3DES
AES
3DES
AES
3DES
AES
3DES
AES
3DES
AES
3DES
AES
3DES
AES
encrypt
0
0
0
0
31
0
328
94
2860
500
16063
4641
116687
98094
decrypt
0
0
0
0
31
0
360
109
2891
547
14984
4250
124969
103813
encrypt
0
0
0
0
15
0
343
109
2859
500
14703
2328
78765
66531
decrypt
0
0
0
0
31
16
375
141
2958
562
16375
4875
110828
74375
encrypt
0
0
0
0
16
0
110
110
1093
1219
9313
6782
87250
58922
decrypt
0
0
0
0
15
0
109
125
1066
1359
7954
7110
66297
60594
11.4 Discussion of the results
The performance of the AES application is higher than the one of the
TripleDES application. This is definitely true for the Java 1.4.2 and Java 1.5
beta application. The difference is less clear for the C# application when
encrypting or decrypting smaller files but is again more clear when
encrypting/decrypting larger files. This can be explained by the fact that one of
the main disadvantages of the TripleDES algorithm its slow encryption speed
[Wikipedia, 2004d] where AES is fast in both software and hardware, is
relatively easy to implement, and requires little memory [Wikipedia, 2004e].
These tests again prove this fact.
From table 4 it is obvious that, when measuring the performance of the
TripleDES algorithm, the C# application is much faster the two Java
applications. The reverse is true for the AES applications, except for the
encryption/decryption of the 100 Mb file. A possible explanation for this can be
the following: Presume the Java compiler optimizes the code for AES
encryption during encryption. This means that the JIT compiler doesn’t need
to be addressed at runtime for the start of AES encryption. Suppose the C#
JIT compiler doesn’t do this optimization. The C# performance would
therefore be depending on the speed of the C# compiler. It is obvious that a
program is slower when it first needs to compile a part of the code. This could
explain why C# is slower then Java in the encryption of smaller files. Then
again, C# is faster in addressing memory then Java, due to the better
integration of the .NET Framework in the Windows OS (see also §12.2.1).
Therefore the C# compilation will catch up to Java and surpass it for larger
files, which would explain why C# encrypts a 100 Mb file faster then Java,
while Java encrypts the smaller file sizes faster.
Since the two algorithms, TripleDES and AES, both have been standardized,
we presume that differences in the performance of the application must be
platform specific.
When looking at the two Java versions (1.4.2 and 1.5 beta), one can see that,
regarding the TripleDES algorithm, there isn’t much of a difference between
them except for the encryption of the 100 Mb file where Java 1.5 beta is faster
then Java 1.4.2. The same is true for the AES algorithm. Java 1.5 beta does
not seem to be an improvement to the performance of the encryption speed.
Again, this conclusions could be better funded by means of a statistical test.
55
12 Conclusions: The performance of Java and .NET
12.1 Which platform/language for P2P applications?
Both Java as .NET seem to be equal, regarding the performance of P2P file
transfer. This is not all that strange considering the fact that TCP as well as
UDP are system independent. The sockets that are being accessed by Java
or the .NET Framework belong to the operating system, which was the same
for both applications.
By using the TCPClient and TCPListener class, files could be send and
received faster without buffering then with buffering, which had to be used to
ensure interoperability. This is also logical because buffering a file takes up
processor time. Buffering a file is more efficient though, because you don’t
have to read the entire file into the system memory before you send it, but you
can read it in little pieces (into a stream), saving a considerable amount of
memory.
For the creation of P2P applications, which seem to gain ground and will
continue to grow in the future, both platforms seem to be adequate. Both
platforms have their advantages and disadvantages, as described in
paragraph 10.1. The existence of JXTA, an open source API, containing a
generalized set of P2P protocols that is produced by Sun Microsystems Inc.,
might give Java a slight advantage over .NET in creating P2P applications. It
might be interesting to see whether such a project will also arise for the .NET
platform in the future. It might even be more interesting to see how efficient
the interoperability between these two systems will be.
12.2 Which platform/language for symmetric encryption?
12.2.1
Memory management
As already explained in paragraph 11.2, the JVM standard has a initial
maximum heap size that is too small to read a 50 Mb (or larger) file in its
memory and encrypt/decrypt it. Therefore we had to start the java applications
using the parameter -Xmx400M to the batch file, used for starting the JARs.
The C# applications did not have this issue. It isn’t even possible to control
the heap size of the CLR. I think this is an important difference between the
JVM and the .NET Framework. The reason for this will be illustrated using the
following analogy. As already discussed in chapter 8, the Java platform is
portable and the .NET platform isn’t (for now). Therefore, the .NET platform
could be integrated in the Windows OS much more. .NET Framework is much
more “at home” then the Java platform. Being “at home” results in the fact that
it is easier for the .NET Framework to “take” any needed resources (as far as
those are available), while the Java Platform behaves more like “a guest” in
someone else his home. Java can’t just take needed resources but has to ask
for them. By means of the command line, one can increase the heap size so
Java can use more memory. This is not possible for the heap size of the CLR.
A nice prove for the fact that .NET just takes the resources it needs can be
obtained by encrypting a 100 Mb file and observing the process table in
Windows XP Task Manager, that shows the memory usage of each separate
process that runs on the system. When using the C# TripleDES application for
the encryption of the file, one can see the memory usage of this application
increase from 2 to 163 Mb, proving that the heap size of the CLR is expanded
when needed. The same applies for the C# AES application (increase in
memory from 2 to 137Mb.).
12.2.2
Which platform to choose?
It is important to note that few “real world” applications will first read a
complete file into their memory before they start the encryption/decryption
process. They will more likely read a small piece of the file into their memory
(for example by means of a Stream) and then encrypt/decrypt it before the
next piece is read. This is much more efficient and saves a lot of memory that
can be used for other processes. Therefore, for this sort of applications only
the results for the smaller file sizes in this test are relevant, considering they
will never have to encrypt large pieces of a file. Looking at table 4, one can
see that for smaller files the performance is equal for both platforms and for
both algorithms.
57
Still the method used for the symmetric encryption performance test was
relevant to the testing of the Java and .NET performance under more extreme
conditions.
12.3 The General Conclusion and remarks for the future.
As security becomes more and more important in modern society, so do the
encryption algorithms. The growing need of secure file transfer and
communication urges for development platforms that can produce reliable and
fast encryption techniques. Both the Java platform as the .NET Framework try
to provide an answer to those needs.
Since most applications that need to encrypt/decrypt a file, read that file into a
stream resulting in small pieces of the file that get encrypted one at a time,
rather then the whole file at once, we can conclude that both platforms
perform equally good. Should there be a need for the encryption of whole files
at once, then the .NET Framework is faster then Java when using the
TripleDES algorithm. Regarding the AES algorithm, Java seems to faster then
the .NET Framework. Also, there doesn’t seem to be a great difference
between Java 1.4.2 and Java 1.5 beta considering the performance during
encryption.
When looking at the performance during P2P file transfer and during
symmetric encryption (for the algorithms that were tested) there doesn’t seem
to be a big difference between the Java Platform and the .NET Framework.
This may be a good sign regarding the growing market for P2P applications,
who will also be in need of good security implementations. Companies can
choose to develop applications on their favorite platform. Existing examples
are messenger programs like ICQ and MSN but also P2P exchange
applications like Gnutella and Kazaa. These applications have need of the file
transfer mechanisms that can securely send data
With an enterprise development market share of 35-40% each, it's fairly
obvious that neither of these two platforms is "leaving" any time soon.
Analysts estimate that by 2005, up to 90% of all IT shops will have both
platforms running side by side. It's clear to even the most zealous Java or
58
.NET devotee that working with both platforms is going to become the norm
[Neward, 2004]. More important, efficient interoperability will become more
and more urgent as parallel applications will need to be able to communicate
with each other.
Making two platforms interact is at once a simple and difficult problem.
Simple, in that it's a fairly closed-requirements solution: if I you work out a few
technical details, interaction is achieved. It is also fairly easy to achieve
success--if they can talk, you did it, if not, there's still work to do. In fact, once
you have worked out low-level issues like byte order, file/data format, and
hardware compatibility, basic interaction between any two platforms is pretty
straightforward. (As a matter of fact on this basis the Internet was built.) But
the problem of integration still presents hardships, owing to the rich
complexity of systems that build on these basic low-level concepts. Merely
because you can exchange TCP/IP packets between a Windows machine
and a Solaris server does not mean that getting .NET code to exchange data
with a J2EE server will be easy - far from it. Numerous hazards lie in wait for
the budding integration developer [Neward, 2004].
This thesis proved that both the Java Platform as the .NET Framework are
about equally performant considering P2P file transfer and symmetric
encryption, as they would be used in a modern P2P application. This is a
good basis for building secure P2P applications on both platforms. A huge but
challenging task will lie in making those applications interoperable in an
efficient way, making sure that not to much performance is lost. This will
definitely improve secure digital communication over larger networks.
59
13 References
Albahari, B. (2000) A comparative overview of C#.
Web link:
http://genamics.com/developer/csharp_comparative.htm#1
Boeynaems, K. (2004): Man-in-the-middle aanval op het SSL
protocol.
Master
thesis.
181
pages.
Web
link:
http://www.lore.ua.ac.be/Publications/pdf/Boeynaems2004.p
df
Byous, J. (1998): Java Technology: The early years. Sun Microsystems.
Web link: http://java.sun.com/features/1998/05/birthday.html
CNNS (2003): CNSS Policy No. 15, Fact Sheet No. 1: National Policy on
the Use of the Advanced Encryption Standard (AES) to Protect
National Security Systems and National Security Information. CNNS. 3
pages. Web link: http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf
Courtois, N., Pieprzyk, J. (2002): Cryptanalysis of Block Ciphers with
Overdefined Systems of Equations. Asiascript. Pages 267–287. Web
link: http://eprint.iacr.org/2002/044.pdf
Drayton, P., Albahari, B., Neward, T. (2003): C# in a nutshell: A
DesktopQuick reference (2nd edition). O'Reilly. 897 pages.
Eckel, B. (2002): Thinking in Java, 3rd edition. Prentice-Hall. 1182 pages
ECMA(a) (2002): ECMA – 334: The C# language specification. ECMA.
490
pages.
Web
link :
http://www.ecma-
international.org/publications/standards/Ecma-334.htm
ECMA(b) (2002): ECMA – 335: Common Language Infrastructure (CLI).
ECMA.
490
pages.
Web
link
http://www.ecma-
international.org/publications/standards/Ecma-335.htm
60
Ferguson, N., Kelsey, J., Lucks, S., Schneier, B., Stay, M. , Wagner, D.,
Whiting, D. (2000): Improved Cryptanalysis of Rijndael. FSE 2000,
pages 213–230. Web link: http://www.schneier.com/paper-rijndael.pdf
Flanagan, D. (2002): Java in a nutshell: A Desktop Quick Reference (4th
edition). O'Reilly. 969 pages.
Gallant, M.I. (2004): Symmetric encryption: .NET, CryptoAPI and Java.
Web link: http://www.jensign.com/JavaScience/dotnet/NetDESEncrypt/
Hughes, D., Warren, I., Sommerville, I. (2004): Improving QoS for Peer-toPeer Applications through Adaptation. Future trends in distributed
computing
systems.
10
pages.
Web
link:
http://polo.lancs.ac.uk/p2p/Documents/FTDCS.pdf
Ikram, A. (2003): Common Language Runtime – CLR. Web link:
http://aishai.netfirms.com/CLR.shtml
ISO/IEC(a) (2003) ISO/IEC 23271: C# Language Specification, first
edition.
ISO/IEC.
486
pages.
Web
link:
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAva
ilableStandards.htm
ISO/IEC(b) (2003) ISO/IEC 23272: Common Language Infrastructure, first
edition
(five
partitions).
ISO/IEC.
522
pages.
Web
link:
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAva
ilableStandards.htm
Jones, B.L. (2001): Sams Teach yourself C# in 21 days. Sams Publishing.
749 pages
Lancaster (2001a) Peer-to-peer: An overview. Lancaster University. 24
pages. Web link: http://polo.lancs.ac.uk/p2p/Documents/Overview.pdf
61
Lancaster (2001b) .Net and JXTA, and their support for P2P. Lancaster
University. 6 pages.
Web link:
http://polo.lancs.ac.uk/p2p/Documents/NetvsJXTA.pdf
Lucks, S. (1998): Attacking Triple Encryption. Fast Software Encryption
1998.
pages
239–253.
Web
link:
http://th.informatik.uni-
mannheim.de/People/Lucks/papers/3des.ps.gz
MacCarthy, M. (2004): The Economics of Network Industries. University of
Georgetown. Web link:
http://cct.georgetown.edu/curriculum/Spring2004/CCTP773.doc
Melville, L., Walkerdine, J., Sommerville, I. (2003): D9 – P2P Reference
architectures (final version). P2P Architect. 71 pages. Web link:
http://polo.lancs.ac.uk/p2p/Documents/RefArch.pdf
Microsoft (2004): Microsoft developer tools roadmap. Microsoft Visual
Studio
Development
Center.
Web
link:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx
Mono Project (2004): What is Mono? Web link: http://www.monoproject.com/about/index.html
MSDN (2004): .NET Framework Class Library: the TcpClient class. Web
link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/frlrfSystemNetSocketsTcpClientClassTopic.asp
Neward, T. (2004): .NET and Java: a study in interoperability.
Developemeter.
6
pages.
Web
link:
http://www.theserverside.net/articles/showarticle.tss?id=Interoperability
Northover, S. (2001): SWT: The standard widget toolkit. PART 1:
Implementation
Strategy
for
Java
Natives.
Web
link:
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design1.html
62
Obasanjo, D. (2001): C# from a Java developer’s perspective. Web link:
http://www.25hoursaday.com/CsharpVsJava.html
Olson, L. (2001): .NET P2P: Writing Peer-to-Peer Networked Apps with
the Microsoft .NET Framework. MSDN Magazine February 2001. Web
link:http://msdn.microsoft.com/msdnmag/issues/01/02/netpeers/default.
aspx
Philipchuk,
D.
(2003a):
Java
vs.
.NET
Security,
Part
1
Security Configuration and Code Containment. O'Reilly Digital
Publications.
Web
link:
http://www.onjava.com/pub/a/onjava/2003/11/26/javavsdotnet.html
Philipchuk,
D.
(2003b):
Java
vs.
.NET
Security,
Part
2
Cryptography and Communication. O'Reilly Digital Publications. Web
link: http://www.onjava.com/pub/a/onjava/2003/12/10/javavsdotnet.html
Philipchuk,
D.
(2004a):
Java
vs.
.NET
Security,
Part
3
Code Protection and Code Access Security (CAS). O'Reilly Digital
Publications.
Web
link:
http://www.onjava.com/pub/a/onjava/2004/01/28/javavsdotnet.html
Philipchuk,
D.
(2004b):
Java
vs.
.NET
Security,
Part
1
User Authentication and Authorization. O'Reilly Digital Publications.
Web
link:
http://www.onjava.com/pub/a/onjava/2004/02/25/javavsdotnet.html
Rijmen,
V.
(2004):
The
Rijndael
page.
Web
link:
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
Schneider, B. (1996): Applied Cryptography: Protocols, Algorithms, and
Source Code in C, 2nd Edition. Wiley & Sons Inc.
Sheil, H., Monteiro, M. (2002): Rumble in the jungle: J2EE versus .Net,
Part 1 - How do J2EE and Microsoft's .Net compare in
enterprise
environments?.
Web
link:
63
http://www.javaworld.com/javaworld/jw-06-2002/jw-0628j2eevsnet_p.html
Shirky, C. (2001): HailStorm: Open web services controlled by Microsoft.
O’Reilly
Open
P2P.com.
Web
link:
http://www.openp2p.com/pub/a/p2p/2001/05/30/hailstorm.html
Sun, (1995): The Java Language: An Overview. Sun Microsystems. 8
pages.
Web
link:
http://java.sun.com/docs/overviews/java/java-
overview-1.html
Sun, (2002a): Security and project JXTA: Sun Microsystems. 4 pages.
Web Link: http://www.jxta.org/project/www/docs/SecurityJXTA.PDF
Sun, (2002b): The Java HotSpot Virtual Machine, v.1.4.1., d2: a technical
whitepaper.
Sun
Microsystems.
28
pages:
Web
link:
http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v
1.4.1/JHS_141_WP_d2a.pdf
Sun, (2004a): J2SE: Java 2 Platform, Standard Edition Platform Overview.
Sun Microsystems. Web link: http://java.sun.com/j2se/overview.html
Sun, (2004b): Java 2 Platform, Enterprise Edition (J2EE) Platform
Overview.
Sun
Microsystems.
Web
link:
http://java.sun.com/j2ee/overview.html
Sun, (2004c): J2SE: Java 2 Platform, Standard Edition Platform Overview.
Sun Microsystems. Web link: http://java.sun.com/j2se/overview.html
Sun, (2004d): J2SE: Java 2 Platform, Standard Edition Platform Overview.
Sun Microsystems. Web link: http://java.sun.com/j2se/overview.html
64
Wienholt, N. (2004): Security Enhancements in the Whidbey Release of
.NET
Framework.
Web
Link:
http://www.dotnetperformance.com/articleitem.aspx?id=31
Wikipedia
(2004a):
Block
Cypher.
Web
Link:
http://en.wikipedia.org/wiki/Block_cipher
Wikipedia (2004b): Block Cypher modes of operation. Web Link:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
Wikipedia
(2004c):
Triple
DES.
Web
Link:
http://en.wikipedia.org/wiki/3DES
Wikipedia
(2004d):
Data
Encryption
Standard.
Web
Link:
http://en.wikipedia.org/wiki/DES
Wikipedia
(2004d):
Advanced
Encryption
Standard.
Web
Link:
http://en.wikipedia.org/wiki/AES
65
Appendix A: A list of used abbreviations
The following table contains frequently used abbreviations.
Abbreviation
(G)UI
3DES
AES
API
BCL
CAS
CBC
CLI
CLR
CLS
COM
CTS
DES
ECB
FCL
HTML
I/O
IL
IP
IV
JCL
JCP
JDK
JIT
JNI
JRE
JVM
JXTA
OS
P2P
PDA
SOAP
TCP
UDP
XML
Explanation
(Graphical) User Interface
TripleDES
Advanced Encryption Standard
Application Programming Interface
Base Class Library
Code Access Security
Cipher Block Chaining
Common Language Interface
Common Language Runtime
Common Language Specification
Component Object Model
Common Type System
Data Encryption Standard
Electronic Code Book
Framework Class Library
HyperText Markup Language
Input/Output
Intermediate Language
Internet Protocol
Intialization Vector
Java Class Libraries
Java Community Process
Java Developement Kit
Just-In-Time
Java Native Interface
Java Runtime Environment
Java Virtual Machine
Juxtapose
Operating System
Peer to Peer
Personal Digital Assistant
Simple Object Access Protocol
Transmission Control Protocol
User Datagram Protocol
Extensible Markup Language
66
Appendix B: The StopWatch class
The Java version
/**
* @author Bert
*
* A class to help benchmark code
* It simulates a real stop watch
*
*@see
http://java.sun.com/docs/books/performance/1st_edition/html/JPMeasure
ment.fm.html#18181
*/
public class StopWatch {
private long startTime = -1;
private long stopTime = -1;
private boolean running = false;
public StopWatch start() {
startTime = System.currentTimeMillis();
running = true;
return this;
}
public StopWatch stop() {
stopTime = System.currentTimeMillis();
running = false;
return this;
}
/** returns elapsed time in milliseconds
* if the watch has never been started then
* return zero
*/
public long getElapsedTime() {
if (startTime == -1) {
return 0;
}
if (running){
return System.currentTimeMillis() - startTime;
} else {
return stopTime-startTime;
}
}
public StopWatch reset() {
startTime = -1;
stopTime = -1;
running = false;
return this;
}
}
67
The C# version
/// <summary>
/// StopWatch used for benchmarking.
/// </summary>
public class StopWatch
{
private long startTime = -1;
private long stopTime = -1;
private bool running = false;
public StopWatch start()
{
startTime = System.DateTime.Now.Ticks / 10000;
running = true;
return this;
}
public StopWatch stop()
{
stopTime = System.DateTime.Now.Ticks / 10000;
running = false;
return this;
}
/// <summary>
/// returns elapsed time in milliseconds
/// if the watch has never been started then
/// return zero
/// </summary>
/// <returns></returns>
public long getElapsedTime()
{
if (startTime == -1)
{
return 0;
}
if (running)
{
return (System.DateTime.Now.Ticks / 10000) - startTime;
}
else
{
return stopTime-startTime;
}
}
public StopWatch reset()
{
startTime = -1;
stopTime = -1;
running = false;
return this;
}
}
68