diff --git a/tnl-1.5.0/README b/tnl-1.5.0/README
new file mode 100644
index 0000000000000000000000000000000000000000..7ad48989a24a0aa52d89193be748e7e6431266ce
--- /dev/null
+++ b/tnl-1.5.0/README
@@ -0,0 +1 @@
+This directory holds the complete distribution of TNL 1.5.0 from SourceForge. We will use it as reference during the process of separating the Torque Network Library and the Torque Network Platform. This directory will be removed when the first stable version of TNL 2.0 is released.
diff --git a/tnl-1.5.0/tnl/LICENSE.txt b/tnl-1.5.0/tnl/LICENSE.txt
new file mode 100644
index 0000000000000000000000000000000000000000..855b2a2a63ebee051c5dec9e934cc1c0e2804777
--- /dev/null
+++ b/tnl-1.5.0/tnl/LICENSE.txt
@@ -0,0 +1,126 @@
+The GNU General Public License (GPL)
+Version 2, June 1991
+
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+Preamble
+
+The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
+
+When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
+
+To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
+
+For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
+
+We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
+
+Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
+
+Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
+
+The precise terms and conditions for copying, distribution and modification follow.
+
+TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
+
+1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
+
+2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
+
+3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
+
+If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
+
+4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
+
+5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
+
+6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
+
+7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
+
+This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
+
+8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
+
+9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
+
+10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
+
+NO WARRANTY
+
+11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+END OF TERMS AND CONDITIONS
+
+How to Apply These Terms to Your New Programs
+
+If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
+
+To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
+
+ one line to give the program's name and a brief idea of what it does.
+ Copyright (C)
+
+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest
+ in the program `Gnomovision' (which makes passes at compilers)
+ written by James Hacker.
+
+ signature of Ty Coon, 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
\ No newline at end of file
diff --git a/tnl-1.5.0/tnl/Makefile b/tnl-1.5.0/tnl/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..e0a2574fe8001e3f40819f9994fa7e10cb6b9045
--- /dev/null
+++ b/tnl-1.5.0/tnl/Makefile
@@ -0,0 +1,19 @@
+default:
+ @$(MAKE) -C tnl
+ @$(MAKE) -C libtomcrypt
+ @$(MAKE) -C master
+ @$(MAKE) -C masterclient
+ @$(MAKE) -C test
+
+.PHONY: clean
+
+clean:
+ @$(MAKE) -C tnl clean
+ @$(MAKE) -C libtomcrypt clean
+ @$(MAKE) -C master clean
+ @$(MAKE) -C masterclient clean
+ @$(MAKE) -C test clean
+
+docs:
+ @$(MAKE) -C docs
+
diff --git a/tnl-1.5.0/tnl/ReadMe.html b/tnl-1.5.0/tnl/ReadMe.html
new file mode 100644
index 0000000000000000000000000000000000000000..03fda833f4a298c6b0fcf33f76ab798d1ec2fc97
--- /dev/null
+++ b/tnl-1.5.0/tnl/ReadMe.html
@@ -0,0 +1,115 @@
+
+
+Torque Network Library Readme
+
+
+
+Torque Network Library
+Readme
+(c) GarageGames 2004
+
+
+
+Developing computational simulations is a complex, interdisciplinary undertaking. To take a simulation of any sort and run it in a distributed environment introduces a whole new world of problems to overcome. The Torque Network Library provides a robust framework for message passing and efficient state replication, built on a UDP-based protocol.
+
+
+
+
+- Portable
+
+ - Platforms
+
+ - Mac OSX
+
- Linux
+
- Win32
+
+ - Compilers
+
+ - Xcode
+
- GCC
+
- Visual C++ 6/7
+
+
+ - Powerful RPC Support
+
+ - Lightweight and efficient - not intended to be a replacement for CORBA.
+
- Extremely easy to use - two simple macro definitions and you're done.
+
- No complex wrapper classes to work with - write and call your functions as you normally would, and TNL will take care of the rest.
+
+ - Robust UDP-based notification protocol
+
+ - Supports fixed or adaptive rate data transfer.
+
- Arbitrary sized packet window.
+
- Robust connection handshaking.
+
- Handles packet loss/out of order delivery.
+
+ - Networked Objects
+
+ - Instantiation of objects by name or ID.
+
- IDs are assigned to NetGroups, so that only objects relevant to a connection can be references.
+
+ - Event Support
+
+ - Unguaranteed, guaranteed unordered, or guaranteed ordered event delivery.
+
- Notification to the event when it has been received or dropped by a client.
+
+ - Ghost Support
+
+ - Most-recent state information is transmitted to clienst.
+
- Scoping of objects to only those clients for which they are relevant - this helps prevent cheating or data sniffing and makes dramatically more effective use of available bandwidth.
+
- Prioritization of state updates by arbitrary criteria, such as relative velocity, team, ownership, etc.
+
+ - Extensible Protocol Architecture
+
+ - Easy to extend the protocol, for instance, to transmit player move information with every packet, or add voice support.
+
- See Torque for examples of additional capabilities that could be added to the protocol.
+
+
+
+
+
+
+
+Under the osx subdirectory there is an XCode project. It is set up to build TNL and the TNLTest app.
+
+
+
+From the top level directory, type
+
+make
+
+If you have OpenGL and wxWindows installed, and OpenGL support enabled in wxWindows, you can build the wxgui test client/server program with
+
+cd test && make wxgui
+
+The wxgui is not built by default.
+
+
+
+There are VC6 and VC7 project workspaces in the root directory of the checkout. Individual project files are in their respective directories.
+
+
+
+The TNL comes with extensive Doxygen documentation. You can access this documentation online at Some URL, or generate it by downloading Doxygen from www.doxygen.org and executing the following command line (assuming you installed Doxygen in the standard place) from the root of your TNL checkout...
+
+
+- Under Windows:
+ "c:\Program Files\doxygen\bin\doxygen.exe" docs\doxygen.html.cfg
+ - Under Linux or OSX:
+ doxygen docs/doxygen.html.cfg
+
+
+This will produce a set of Doxygen docs in the docs\html subdirectory of your TNL checkout. Please note that these docs may ONLY be distributed to other TNL licensees.
+
+
+
\ No newline at end of file
diff --git a/tnl-1.5.0/tnl/cwPrefixWin32.h b/tnl-1.5.0/tnl/cwPrefixWin32.h
new file mode 100644
index 0000000000000000000000000000000000000000..c373e5ec778df5573c00758a63c7f8758af96d64
--- /dev/null
+++ b/tnl-1.5.0/tnl/cwPrefixWin32.h
@@ -0,0 +1,11 @@
+// prefix include file for Metrowerks CodeWarrior
+
+#define TNL_DEBUG
+
+// enable to have TNL asserts or logging
+//#define TNL_ENABLE_ASSERTS
+//#define TNL_ENABLE_LOGGING
+
+// You might also want to call TNLLogEnable(xyz, true) to enable special
+// logging output. xyz could be LogNetConnection, LogNetConnection, e.t.c.
+// See tnlLog.h for more logging targets.
diff --git a/tnl-1.5.0/tnl/docs/Makefile b/tnl-1.5.0/tnl/docs/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..8fb5d400e87ff7b77dda105da8c0e543bc9c79fa
--- /dev/null
+++ b/tnl-1.5.0/tnl/docs/Makefile
@@ -0,0 +1,26 @@
+default: tree html
+
+tree: doxytree.html.cfg
+ @echo --- Building docs...
+ cd .. && doxygen docs/doxytree.html.cfg
+ @echo --- Copying images...
+ cp -r images doxytree
+ rm -rf doxytree/images/CVS
+ @echo --- Applying frameset patch...
+ echo `cp -v tree_overlay/* doxytree`
+ @echo --- Pushing docs live...
+ mv ../../../htdocs/doxytree ./tmp1
+ mv -fv doxytree ../../../htdocs/
+ rm -rf ./tmp1
+
+html: doxygen.html.cfg
+ @echo --- Building docs...
+ cd .. && doxygen docs/doxygen.html.cfg
+ @echo --- Copying images...
+ cp -r images doxydocs
+ rm -rf doxydocs/images/CVS
+ @echo --- Pushing docs live...
+ mv ../../../htdocs/doxydocs ./tmp2
+ mv -fv doxydocs ../../../htdocs/
+ rm -rf ./tmp2
+
diff --git a/tnl-1.5.0/tnl/docs/doco.css b/tnl-1.5.0/tnl/docs/doco.css
new file mode 100644
index 0000000000000000000000000000000000000000..c1f79abc1b659a9ee9abeef86268ada2a55d2f31
--- /dev/null
+++ b/tnl-1.5.0/tnl/docs/doco.css
@@ -0,0 +1,382 @@
+.article a { color: #8D0000; font-weight: bold; text-decoration: none }
+.article a:visited { color: #AAAAAA; }
+.article a:hover { text-decoration: underline; }
+
+a { color: #8D0000; font-weight: bold; text-decoration: none }
+a:visited { color: #AAAAAA; }
+a:hover { text-decoration: underline; }
+
+a.code {
+ color: #4444EE;
+ font-weight: normal;
+ text-decoration: none;
+}
+
+a.coderef {
+ color: #4444EE;
+ font-weight: normal;
+}
+
+a:link {
+ color: #900000;
+ text-decoration: underline;
+}
+
+a:visited {
+ color: #900000;
+ text-decoration: underline;
+}
+
+a:hover {
+ color: #B52010;
+ color: #B52010;
+ text-decoration: underline;
+}
+
+a.code{
+ color: #900000;
+ font-weight: normal;
+ text-decoration: underline;
+}
+
+a.coderef{
+ color: #436976;
+ font-weight: normal;
+}
+
+a.el {
+ font-weight: normal;
+ text-decoration: underline;
+}
+
+a.qindex{
+ font-weight: normal;
+ white-space: nowrap;
+}
+
+a.qindexhl, a.qindexrefhl {
+ color: #FFFFFF;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+a.qindexref{
+}
+
+body {
+ background: #FFFFFF;
+ color: #000000;
+ font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
+ font-size: 75%;
+ margin: 0;
+}
+
+caption, a.elref {
+ font-weight: bold;
+}
+
+div.ah {
+ background-color: #000000;
+ color: #FFFFFF;
+ font-weight: bold;
+ margin-bottom: 3px;
+ margin-top: 3px;
+}
+
+div.footer{
+ background: #B0C2D7;
+ border: 1px solid #436976;
+ color: #000000;
+ font-style: normal;
+ margin-top: 5em;
+ padding-bottom: 3px;
+ text-align: center;
+}
+
+div.fragment{
+ background: #FFFFDD;
+ border: 1px solid #CCCCCC;
+ margin-bottom: 1em;
+ margin-top: 1em;
+ padding-left: 1em;
+ padding-right: 1em;
+}
+
+DIV.fragment {
+ width: 95%;
+ background-color: #f0f0f0;
+ border: 1px solid black;
+ padding: 5px;
+ margin-left: 10px;
+ margin-right: 10px;
+ font-size: 150%;
+}
+
+div.groupheader{
+ border-bottom: 1px solid #557E8C;
+ font-weight: bold;
+ margin-bottom: 6px;
+ margin-left: 16px;
+ margin-top: 12px;
+}
+
+div.grouptext{
+ font-style: italic;
+ margin-left: 16px;
+}
+
+div.header{
+ background: #B0C2D7;
+ border: 1px solid #436976;
+ color: #000000;
+ font-style: normal;
+ margin-bottom: 1em;
+ padding-bottom: 3px;
+ padding-left: 10px;
+ text-align: left;
+ text-transform: lowercase;
+}
+
+div.header a, div.footer a{
+ color: #436976;
+ font-size: 90%;
+ margin-right: 1em;
+ font-weight: normal;
+ white-space: nowrap;
+}
+
+div.header a:visited, div.footer a:visited {
+ color: #325865;
+}
+
+div.header a:hover, div.footer a:hover, a.anchor:hover {
+ color: #A41005;
+ text-decoration: none;
+}
+
+div.index {
+ padding-right: 10px;
+ text-align: center;
+}
+
+div.maindox {
+ margin: 2%;
+ width: 96%;
+}
+
+div.nav {
+ float: left;
+}
+
+div.qindex {
+ background-color: #EEEEFF;
+ border: 4px solid #EEEEFF;
+ margin-bottom: 2px;
+ text-align: center;
+ width: 100%;
+}
+
+dl.el {
+ margin-left: -1cm;
+}
+
+font.charliteral, span.charliteral {
+ color: #008080;
+}
+
+font.comment, span.comment {
+ color: #00A000;
+}
+
+font.keyword, span.keyword {
+ color: #0000FF;
+}
+
+font.keywordflow, span.keywordflow {
+ color: #0080F0;
+}
+
+font.keywordtype, span.keywordtype {
+ color: #0000D0;
+}
+
+font.preprocessor, span.preprocessor {
+ color: #FF7000;
+}
+
+font.stringliteral, span.stringliteral {
+ color: #002080;
+}
+
+h1{
+ font-size: 220%;
+ text-align: center;
+}
+
+h2{
+ border-bottom: 2px solid #557E8C;
+ font-size: 170%;
+}
+
+hr {
+ border: 1px solid #000000;
+}
+
+img.formuladsp {
+}
+
+img.formulainl {
+ vertical-align: middle;
+}
+
+p.formuladsp {
+ text-align: center;
+}
+
+td {
+ font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
+ font-size: 75%;
+}
+
+td.indexkey{
+ background: #EEEEFF;
+ font-weight: bold;
+ margin: 2px 0px;
+ padding: 2px 10px;
+}
+
+td.indexvalue{
+ background: #EEEEFF;
+ font-style: italic;
+ margin: 2px 0px;
+ padding: 2px 10px;
+}
+
+td.md{
+ font-weight: bold;
+ font-size: 85%;
+}
+
+td.mdname, td.mdname1 {
+ color: #FF9900;
+ font-weight: bold;
+ font-size: 85%;
+}
+
+tr.memlist {
+ background-color: #F0F0F0;
+}
+
+ul {
+ list-style-type: square;
+}
+
+.mdrow {
+ padding: 1ex 1em;
+ font-size: 85%;
+}
+
+.mdtable {
+ background: #F0F0FA;
+ margin-bottom: 1ex;
+}
+
+.mdescleft {
+ background-color: #F0F0FA;
+ margin: 0px;
+ padding-left: 8px;
+}
+
+.mdescright {
+ background-color: #F0F0FA;
+ font-style: italic;
+ margin: 0px;
+ padding-bottom: 0px;
+ padding-left: 4px;
+ padding-right: 8px;
+ width: 100%;
+}
+
+.memitemleft {
+ background-color: #F0F0FA;
+ border-top: 2px solid #FFFFFF;
+ font-size: 85%;
+ margin: 4px;
+ padding: 1px 0px 0px 8px;
+}
+
+.memitemright {
+ background-color: #F0F0FA;
+ border-top: 2px solid #FFFFFF;
+ font-size: 85%;
+ margin: 4px;
+ padding: 1px 0px 0px 8px;
+}
+
+
+/* CSS Document */
+body {
+ background-color: #FFFFFF;
+ font-family: Arial, Helvetica, sans-serif;
+ font-size: 8pt;
+ color: Black;
+}
+
+hr {
+ color: #333366;
+ background-color:transparent
+}
+i, em { font-style: italic; }
+b, strong { font-weight:bold; }
+.tiny { font-size: 7pt; }
+.grey {
+ font-size: 8pt;
+ color: #909090;
+ background-color:transparent
+}
+
+h1,h2,h3,h4 { color:black; background-color:transparent; font-weight:bold; margin-top:.25em;margin-bottom:.25em }
+h1 { font-size:200%; }
+h2 { font-size:150%; }
+h3 { font-size:120%; }
+h4 { font-size:100%; }
+
+
+/* Article Style ----------------*/
+/*-------------------------------*/
+.article {
+ vertical-align:top;
+ text-align:left;
+ font-size: 12px;
+ color:black;
+ background-color: #FFFFFF;
+ padding-top: 4px;
+ padding-right: 4px;
+ padding-bottom: 0px;
+ padding-left: 4px;
+}
+
+.article .title {
+ vertical-align:top;
+ background-color: #1A1B4D;
+ text-align:left;
+ font-weight: bold;
+ color: white;
+ padding:2px 2px 2px 6px;
+}
+
+.article .body {
+ text-align:left;
+ border-width:2px;
+ border-style:solid;
+ border-color:#1A1B4D;
+ background-color: white;
+ color: black;
+ padding:3px;
+}
+
+.article .freetext {
+ padding:5px;
+ font-size: 8px;
+}
+
diff --git a/tnl-1.5.0/tnl/docs/docs.plaintext.txt b/tnl-1.5.0/tnl/docs/docs.plaintext.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e5556aef8db9a147dae7ee87f485d8f2380fa26e
--- /dev/null
+++ b/tnl-1.5.0/tnl/docs/docs.plaintext.txt
@@ -0,0 +1,519 @@
+Preface
+
+The Torque Network Library is a networking API designed to allow developers to easily add world-class multiuser simulation capabilities to their products. The TNL has proven successful in some of the most demanding multiplayer internet games and has gone through years of steady, evolutionary improvement.
+
+Scope of This Documentation
+
+Getting Started gives new users the information they need to download TNL source files, set up projects on supported compilers, and build and run the library and example programs.
+
+History of the TNL gives a brief history of the Torque Network Library from its origins as the network technology behind Sierra/Dynamix's Starsiege: TRIBES to its current status as a standalone network programming solution.
+
+Introduction to Network Programming Concepts introduces the developer to some of the basic concepts of network programming, including fundamental limitations of data networks, standard protocols, application network topologies, security and the hurdles the TNL will help them overcome in providing a consistent simulation on an unreliable communications medium.
+
+Introduction to the Torque Network Library Fundamentals describes the general strategies used in the TNL to overcome the inherent limitations of today's networks.
+
+Torque Network Library Architecture gives an overview of the major classes in the TNL, from the basic Socket layer to the advanced state replication facilities provided by the GhostConnection and NetObject layer.
+
+Torque Network Library Tutorials and Examples walks the developer through the sample programs provided with the TNL, including a simple, networked "Hello World!" program, the TNLTest graphical multiuser simulation and the master server and masterclient test program.
+
+We presume the reader is familiar with C++ programming and concepts.
+
+Acknowledgments
+Tom St. Denis - libtomcrypt
+
+Ari Juels and John Brainard for their work on Client Puzzles.
+
+Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo of the Helsinki University of Technology for their work on DoS resistant Authenticat with Client Puzzles
+
+
+Getting Started
+
+Getting started with the Torque Network Library is a fairly simple process.
+
+1. Get a CVS client for your computer (What is CVS?)
+ Download WinCVS 1.3 for Windows systems
+ Download MacCVSX for computers running Mac OS X
+ Download CVS for linux/unix systems
+
+2. Use CVS to download the current version of the TNL
+ Downloading TNL using WinCVS
+ Downloading TNL using MaxCVSX
+ Downloading TNL using CVS
+
+3. Build TNL using your C++ compiler
+ Build TNL using Microsoft Visual C++ 6.0
+ Build TNL using Microsoft Visual Studio .NET 2003
+ Build TNL using XCode on Mac OS X
+ Build TNL using make on linux
+
+4. Run the example programs
+ TNLTest - the simple TNL example "game"
+ master and masterclient - an example master server for listing game servers
+
+Troubleshooting and Questions
+
+If you have any difficulties or questions downloading, building and running TNL or the example programs, check the FAQ first to see if an answer to your problem already exists. If that doesn't help, you can search or ask in the TNL Private Forums for assistance.
+
+
+What is CVS
+Getting CVS
+Downloading CVS
+Building TNL
+Running example programs
+
+
+With that overview complete, you should now have a working version of the Torque Network Library and its sample programs up and running on your computer.
+
+History of the Torque Network Library
+
+Near the end of 1997, a team of developers at Dynamix were hard at work on a new, network only game that would push the requirements of internet gaming technology to a new level. Starsiege: TRIBES allowed up to 32 players to compete in seamless indoor and outdoor areas with futuristic weapons, jet packs and vehicles.
+
+Unlike other games at the time that were limited to tight indoor environments, the TRIBES environment posed a more difficult set of networking problems. Because of their open nature, clients in the game could often see most of the other players, along with a large number of projecticles and simulated vehicles, turrets and other objects. Also, given the state of most internet connections at the time, it was decided that TRIBES must run well even over a 28.8 kbps modem, imposing a meager 2 Kbytes per second of bandwidth limitation on each client.
+
+With these requirements in mind, Mark Frohnmayer, Rick Overman and Tim Gift designed a network architecture that would maximize the information value of every bit transmitted over the network, and created a new "Notify" protocol that harnessed the unreliable nature of the network transport medium to eliminate unnecessary retransmission of information.
+
+The Tribes Network Architecture was further refined during the development of Tribes 2 to server more players (up to 100 in a single gaming area served by a 1GHz Pentium III) and save even more packet data space, introducing the concept of a network string table and only periodic control object state updating during client-side prediction.
+
+When the Tribes 2 engine became GarageGames' Torque Game Engine, additional iterative improvements were made, including checksums on client state data and a new network interface class to encapsulate the connection startup and prevent connection depletion Denial-of-Service attacks.
+
+The final step in the history of the Torque Network Library was to refactor its constituent parts into a standalone network technology that didn't require any other components from the Torque Game Engine. As a part of this process, significant library structural improvements were made; every class and class member were documented, and strong encryption support was added. Other new features include a simple and powerful Remote Procedure Call (RPC) mechanism, client puzzles for protecting servers from server CPU depletion Denial-of-Service attacks, and 3rd-party negotiated direct connections to connect clients behind firewalls and NAT (Network Address Translation) routers, making TNL a robust, full-featured, secure networking solution for a wide variety of applications.
+
+
+Introduction to Network Programming Concepts
+
+Computer networking technology allows computers that share the network to send messages to one another. Computer networks vary greatly in complexity, from two machines connected together with a link cable, to the globe-spanning internet connecting millions of machines together over fiber-optics, satellite links, phone lines and other mediums.
+
+Fundamental Limitations of Computer Networks
+
+Computer networks of any size share some common limitations to varying degrees that must be accounted for in network simulations, with the internet being the most limited in all three regards. These three fundamental problems in network simulation are:
+
+Limited Bandwidth - There is a limit to the rate at which hosts on the network can send data to one another. If a computer is connected to the network with a 56 kbps modem, this might be 5 Kbytes per second, while computers on a local area network might be able to communicate at 128 megabytes per second. For service providers, additional bandwidth capacity can be costly, so even if there is no physical bandwidth limitation, bandwidth conservation is important for many projects.
+
+Packet Loss - Computer networks are inherently unreliable. Information transmitted over a network may become corrupted in transit, or may be dropped at a router where traffic has become congested. Even when (especially when) using a guaranteed message delivery protocol such as TCP, the unreliable nature of the underlying network still must be taken into account for network applications.
+
+Latency - Messages sent from one host to another on the network take time to arrive at the destination. The time can be influenced by many factors, including the medium over which the messages travel, how many intermediate hosts must route the message, an the level of traffic congestion at each of those network nodes. Latency becomes particularly problematic in network simulations that attempt to present a real-time interface to the client, when the latency of the connection may be perceptible in time.
+
+Standard Network Protocols
+
+When computers communicate over networks, they send and receive data using specific network protocols. These protocols ensure that the computers are using the same specifications to address, forward and process data on the network. The internet, certainly the most widely used computer network today, uses a stack of three primary protocols that facilitate communication over the network. They are:
+
+IP - Internet Protocol: The Internet Protocol is the basic building block for internet communications. IP is a routing protocol, which means that it is used to route information packets from a source host to a destination host, specified by an IP address. IP packets are not guaranteed to arrive at the destination specified by the sender, and those packets that do arrive are not guaranteed to arrive in the order they were sent. IP packet payloads may also be corrupted when they are delivered. IP is not useful as an application protocol - it is used mainly as a foundation for the higher level TCP and UDP protocols.
+
+UDP - User Datagram Protocol: The User Datagram Protocol supplies a thin layer on top of IP that performs error detection and application level routing on a single host. UDP packets are addressed using both an IP address to specify the physical host, and a port number, to specify which process on the machine the packet should be delivered to. UDP packets also contain a checksum, so that corrupted packets can be discarded. UDP packets that are corrupted or dropped by an intermediate host are not retransmitted by the sender, because the sender is never notified whether a given packet was delivered or not.
+
+TCP/IP - Transmission Control Protocol: TCP was designed to make internet programming easier by building a reliable, connection-based protocol on top of the unreliable IP. TCP does this by sending acknowledgements when data packets arrive, and resending data that was dropped. TCP is a stream protocol, so the network connection can be treated like any other file stream in the system. TCP is not suitable for simulation data, because any dropped packets will stall the data pipeline until the dropped data can be retransmitted.
+
+Network Protocols and TNL
+
+Some network systems use both TCP and UDP - TCP for messages that must arrive, but are not time sensitive, and UDP for time-sensitive simulation updates. The next chapter discusses why this is not optimal for bandwidth conservation, and explains the protocol solution implemented in TNL.
+
+Berkeley (BSD) Sockets - the standard network API
+
+The BSD Sockets API describes a set of C language interface routines for communicating using the TCP protocol suite, including IP and UDP. The sockets API allows processes to open communcation "sockets" that can then be assigned to a particular integer port number on the host.
+
+Sockets created to use the TCP stream protocol can either be set to "listen()" for connections from remote hosts, or can be set to "connect()" to a remote host that is currently listening for incoming connections. Once a connection is established between two stream sockets, either side can send and receive guaranteed data to the other.
+
+Sockets can also be created in datagram mode, in which case they will use the underlying UDP protocol for transmission of datagram packets. Since the datagram socket mode is connectionless, the destination IP address and port must be specified with each data packet sent.
+
+The socket API contains other utility routines for performing operations such as host name resolution and socket options configuration. The Microsoft Windows platform supplies a Windows socket API called Winsock that implements the BSD socket API.
+
+Application Network Topologies
+
+Networked applications can be designed to communicate with each other using different topological organization strategies. Some common communcations organization paradigms are discussed below.
+
+Peer-to-Peer: In a peer-to-peer network application, the client processes involved in the network communicate directly with one another. Though there may be one or more hosts with authoritative control over the network of peers, peer-to-peer applications largely distribute the responsibility for the simulation or application amongst the peers.
+
+Client-Server: In the client-server model, one host on the network, the server, acts as a central communications hub for all the other hosts (the clients). Typically the server is authoritative, and is responsible for routing communication between the several clients.
+
+Client-Tiered Server Cluster: In network applications where more clients want to subscribe to a service than can be accomodated by one server, the server's role will be handled by a cluster of servers peered together. The servers in the network communicate using the peer-to-peer model, and communicate with the clients using the client-server model. The servers may also communicate with an authoritative "super-server" to handle logins or resolve conflicts.
+
+TNL imposes no specific network topology on applications using it.
+
+Security and Encryption
+
+When a message is sent between two hosts on a network, that message may pass through any number of intermediate wires, hosts and routers or even sent wirelessly to a satellite or a WiFi base station. This opens up the potential that some third party who has access to any one of the intermediate communication forwarding points may eavesdrop on and/or change the contents of the message. Often networked applications send sensitive user data, like credit card numbers, bank account information or private correspondence. These applications rely on encryption algorithms to protect messages sent over an unsecure network.
+
+Symmetric Encryption
+
+Symmetric Encryption algorithms operate under the assumption that the two parties sending messages to each other share a common, secret key. This key is used to encode the data in such a way that only users with the secret key can decode it. In the ideal case, the ciphertext (encoded version of the message) looks like a random string of bits to any eavesdropper.
+
+There are many Symmetric Encryption algorithms of varying levels of security, but all of them when used alone have several drawbacks. First, both parties to the communication must have a copy of the shared secret key. If a client is attempting to communicate with a service it has never contacted before, and doesn't share a key with, it won't be able to communicate securely with it. Also, although an intermediate eavesdropper cannot read the data sent between the hosts, it can alter the messages, potentially causing one or more of the systems to fail.
+
+Message Authentication
+
+In order to detect when a message has been altered by a third party, a secure messaging system will send a message authentication code (MAC) along with the data. The MAC is generated using a cryptographically secure hashing function, such as MD5 or SHA. Secure hash algorithms take an array of bytes and compute a cryptographically secure message digest of some fixed number of bytes - 16 in the case of MD5, 32 for SHA-256 and so on.
+
+When a message is sent using a symmetric cipher, the hash or some portion of it is encrypted and sent along as well. Any changes in the message will cause the hash algorithm to compute a different hash than that which is encrypted and included with the message, notifying the receiving party that the message has been tampered with.
+
+Public Key Cryptography and Key Exchange
+
+Public Key Cryptography algorithms were invented to solve the symmetric key distribution problem. In public key algorithms, each participant in the communication has a key pair composed of a public key and a private key. The theory of public keys suggests that a message encrypted with the public key can only be decrypted with the private key and vice-versa.
+
+Key exchange algorithms (Diffie-Helman, ECDH) have certain properties such that two users, A and B can share their public keys with each other in plain text, and then, using each other's public key and their own private keys they can generate the same shared secret key. Eavesdroppers can see the public keys, but, because the private keys are never transmitted, cannot know the shared secret. Because public key algorithms are computationally much more expensive than symmetric cryptography, network applications generally use public key cryptography to share a secret key that is then used as a symmetric cipher key.
+
+Digital Signatures/Certificate Authorization
+
+Public key algorithms still have one vulnerability, known as the Man-in-the-Middle attack. Basically, an eavesdropper in the communication between A and B can intercept the public keys in transit and substitute its own public key, thereby establishing a secure connection with A and B - decrypting incoming data and reencrypting it with its shared key to the opposite party.
+
+To combat this attack, the concept of certificates was introduced. In this model, the public key of one or both of the participants in the communication is digitally signed with the private key of some known, trusted Certificate Authority (CA). Then, using the Certificate Authority's public key, the parties to the communication can validate the public key of the opposite parties.
+
+Security and the TNL
+
+The TNL uses the publicly available libtomcrypt (http://libtomcrypt.org) as its encryption foundation. The TNL features key exchange, secret session keys, message authentication and certificate verification. See <> for more information.
+
+More Information on Cryptography
+
+The preceding sections were only a very high level overview of some cryptographic algorithm theories. For more information, see the USENET cryptography FAQ at http://www.faqs.org/faqs/cryptography-faq/
+
+Additional Challenges Facing Network Programmers
+
+Malicious Attackers and Denial of Service
+
+A problem facing developers of internet applications and web sites are Denial-of-Service attacks. Malicious users employing custom tools often attempt to shut down publicly available internet servers. There are a variety of well-known categories of DoS attacks.
+
+Traffic flooding: This attack sends a barrage of data to the public address of the server, in an attempt to overwhelm that server's connection to the internet. This attack often employs many machines, hijacked by the attacker and acting in concert. These attacks are often the most difficult to mount since they require a large number of available machines with high-speed internet access in order to attack a remote host effectively.
+
+Connection depletion: The connection depletion attack works by exploting a weakness of some connection based communications protocols. Connection depletion attacks work by initiating a constant flow of spurious connection attempts. When a legitimate user attempts to connect to the server, all available pending connection slots are already taken up by the spoofed connection attempts, thereby denying service to valid clients.
+
+Server CPU depletion: If the server performs public key cryptography as part of the connection sequence, a malicious client could be constructed to initiate bogus connection attempts in an effort to initiate many CPU intesive cryptographic operations on the server.
+
+The TNL uses a two-phase connection protocol to protect against connection depletion attacks, and implements a client-puzzle algorithm to prevent CPU depletion attacks. Also, TNL is built so that bogus packets are discarded as quickly as possible, preventing flooding attacks from impacting the server CPU.
+
+Firewalls and Network Address Translation (NAT) routers
+
+Firewalls are software or hardware devices designed to protect local networks from malicious external attackers. Most firewalls filter all incoming, unsolicited network traffic. NAT routers exist to allow potentially many machines to share a single IP address, but for practical purposes they share similar characteristics with firewalls, by often filtering out unsolicited network traffic.
+
+In client/server applications, firewalls and NATs aren't generally a problem. When a client behind a firewall or NAT makes a request to the server, the response is allowed to pass through the firewall or NAT because the network traffic was solicited first by the client.
+
+In peer-to-peer applications, NATs and firewalls pose a greater challenge. if both peers are behind different firewalls, then getting them to communicate to each other requires that they both initiate the connection in order for the other's data to be able to flow through the firewall or NAT. This can be facilitated by a third party server or client that both are able to communicate with directly.
+
+The TNL provides functionality for arranging a direct connection between two firewalled hosts via a third party master server. See chapter <> for more information.
+
+Torque Network Library Design Fundamentals
+
+The Torque Network Library was designed to overcome, as much as possible, the three fundamental limitations of network programming - high packet latency, limited bandwidth and packet loss. The following strategies were identified for each of the limitations:
+
+Bandwidth conservation
+
+Bandwidth conservation in multiuser simulations is of premium importance, not only for clients that may be connected over very low bandwidth transports, but also for servers whose operators have to pay for bandwidth usage. Realizing this, the following techniques are used to conserve bandwidth as much as possible:
+
+Send static data once, or not at all: Often in a networked application, a server will transmit some amount of static data to a client. This data may be initialization parameters for a 3D world, a client's name, or some object state that is immutable for objects of a given type. TNL provides direct facilities for caching string data (client names, mission descriptions, etc), sending a given string only once and an integer representation thereafter. The Torque Game Engine also shows how simulations can cache common object instance data in DataBlock objects, which are transmitted only when a client connects.
+
+Compress data to the minimum space necessary: When conserving bandwidth, every bit counts. TNL uses a utility class call BitStream to write standard data types into a packet compressed to the minimum number of bits necessary for that data. Boolean values are written as a single bit, integer writes can specify the bit field width, and floating point values can be specified as 0 to 1 compressed to a specified bit count. The BitStream also implements Huffman compression of string data and compression of 3D positions and surface normals.
+
+Only send information that is relevant to the client: In a client/server simulation, the server often has information that is not relevant at all to some or all of the clients. For example, in a 3D world, if an object is outside the visible distance of a given client, there is no reason to consume valuable packet space describing that object to the client. The TNL allows the application level code to easily specify which objects are relevant, or "in scope" for each client.
+
+Prioritize object updates: Because bandwidth is limited and there is generally a much greater amount of data a server could send to a given client than it has capacity for, the TNL implements a very fine-grained prioritization scheme for updating objects. User code can determine the policy by which objects are judged to be more or less "important" to each client in the simulation, and objects with more importance are updated with a greater frequency.
+
+Only update the parts of an object that have changed: Often in a networked simulation, not all object state is updated at the same time - for exampe, a player in a 3D action game may have state that includes the player's current position, velocity, health and ammunition. If the player moves, only the position and velocity states will change, so sending the full state, including the health and ammunition values would waste space unnecessarily. The TNL allows objects individual objects to have state that are updated independently of one another.
+
+Coping with Packet Loss
+
+In any networked simulation, packet loss will be a consideration - whether because of network congestion, hardware failure or software defects, some packets will inevitably be lost. One solution to the packet loss problem is to use a guaranteed messaging protocol like TCP/IP. Unfortunately, TCP has some behavioral characteristics that make it a poor choice for real-time networked simulations.
+
+TCP guarantees that all data sent over the network will arrive, and will arrive in order. This means that if a data packet sent using TCP is dropped in transit, the sending host must retransmit that data before any additional data, that may have already arrived at the remote host, can be processed. In practice this can mean a complete stall of ANY communications for several seconds. Also, TCP may be retransmitting data that is not important from the point of view of the simulation - holding up data that is.
+
+The other possible protocol choice would be to use UDP for time critical, but unguaranteed data, and use TCP only for data that will not hold up the real-time aspects of the simulation. This solution ends up being non-optimal for several reasons. First, maintaining two communications channels increases the complexity of the networking component. If an object is sent to a client using the guaranteed channel, unguaranteed messages sent to that object at a later time may arrive for processing before the original guaranteed send. Also, because the unguaranteed channel may lose information, the server will have to send more redundant data, with greater frequency.
+
+To solve these problems, TNL implements a new network protocol that fits somewhere between UDP and TCP in its feature set. This protocol, dubbed the "Notify" protocol, does not attempt to hide the underlying unreliability of the network as TCP does, but at the same time it provides more information to the application than straight UDP. The notify protocol is a connection-oriented unreliable communication protocol with packet delivery notification. When a datagram packet is sent from one process, that process will eventually be notified as to whether that datagram was received or not. Each data packet is sent with a packet header that includes acknowledgement information about packets the sending process has received from the remote process. This negates the need for seperate acknowledgement packets, thereby conserving additional bandwidth.
+
+The notify protocol foundation allows the TNL to provide a rich set of data transmission policies. Rather than simply grouping data as either guaranteed or unguaranteed, the TNL allows at least five different categorizations of data:
+
+Guaranteed Ordered data: Guaranteed Ordered data are data that would be sent using a guaranteed delivery protocol like TCP. Messages indicating clients joining a simulation, text messages between clients, and many other types of information would fall into this category. In TNL, Guaranteed Ordered data are sent using Event objects and RPC method calls. When the notify protocol determines that a packet containing guaranteed ordered data was lost, it requeues the data to be sent in a future packet.
+
+Guaranteed data: TNL processes Guaranteed data is in a way similar to Guaranteed Ordered data, with the only difference being that a client can process Guaranteed data as soon as it arrives, rather than waiting for any ordered data to arrive that was dropped.
+
+Unguaranteed data: Unguaranteed data is sent, and if the packet it is sent in arrives, is processed. If a packet containing unguaranteed data events is dropped, that data is not resent. The unguaranteed data sending policy could be used for information like real-time voice communication, where a retransmitted voice fragment would be useless.
+
+Current State data: For many objects in a simulation, the client isn't concerned with "intervening" states of an object on the server, but only its current state. For example, in a 3D action game, if an enemy player moves from point A to B to C, another client in the simulation is only interested in the final position, C of the object. With the notify protocol, TNL is able to resend object state from a dropped packet only if that state was not updated in a subsequent packet.
+
+Quickest Delivery data: Some information sent in a simulation is of such importance that it must be delivered as quickly as possible. In this situation, data can be sent with every packet until the remote host acknowledges any of the packets known to contain the data. Client movement information is an example of data that might be transmitted using this policy.
+
+By implementing various data delivery policies, the TNL is able to optimize packet space utilization in high packet loss environments.
+
+Strategies for Dealing With Latency
+
+Latency is a function of the time-based limitations of physical data networks. The time it takes information to travel from one host to another is dependent on many factors, and can definitely affect the user's perceptions of what is happening in the simulation.
+
+For example, in a client-server 3D simulation, suppose the round-trip time between one client and server is 250 milliseconds. If the client is observing an object that is moving. If the server is sending position updates of the object to the client, those positions will be "out of date" by 125 milliseconds by the time they arrive on the client. Also, suppose that the server is sending packets to the client at a rate of 10 packets per second. When the next update for the object arrives at the client, it may have moved a large distance relative to the perceptions of the client.
+
+Also, if the server is considered to be authoritative over the client's own position in the world, the client would have to wait at least a quarter of a second before its inputs were validated and reflected in its view of the world. This gives the appearance of very perceptible input "lag" on the client.
+
+In the worst case, the client would always see an out of date version of the server's world, as objects moved they would "pop" from one position to another, and each keypress wouldn't be reflected until a quarter of a second later. For most real-time simulations, this behavior is not optimal.
+
+Because TNL is predominantly a data transport and connection management API, it doesn't provide facilities for solving these problems directly. TNL provides a simple mechanism for computing the average round-trip time of a connection from which the following solutions to connection latency issues can be implemented:
+
+Interpolation: Interpolation is used to smoothly move an object from where the client thinks it is to where the server declares it to be over some short period of time. Parameters like position and rotation can be interpolated using linear or cubic interpolation to present a consistent, no "pop" view of the world to the client. The downside of interpolation when used alone is that it actually exacerbates the time difference between the client and the server, because the client is spending even more time than the one-way message time to move the object from its current position to the known server position.
+
+Extrapolation: To solve the problem of out-of-date state information, extrapolation can be employed. Extrapolation is a best guess of the current state of an object, given a known past state. For example, suppose a player object has a last known position and velocity. Rather than placing the player at the server's stated position, the player object can be placed at the position extrapolated forward by velocity times the time difference.
+
+In the Torque Game Engine, player objects controlled by other clients are simulated using both interpolation and extrapolation. When a player update is received from the server, the client extrapolates that position forward using the player's velocity and the sum of the time it will use to interpolate and the one-way message time from the server - essentially, the player interpolates to an extrapolated position. Once it has reached the extrapolated end point, the player will continue to extrapolate new positions until another update of the obect is received from the server.
+
+By using interpolation and extrapolation, the client view can be made to reasonably, smoothly approximate the world of the server, but neither approach is sufficient for real-time objects that are directly controlled by player input. To solve this third, more difficult problem, client-side prediction is employed.
+
+Client-side prediction is similar to extrapolation, in that the client is attempting to guess the server state of an object the server has authority over. In the case of simple extrapolation, however, the client doesn't have the benefit of the actual input data. Client-side prediction uses the inputs of the user to make a better guess about where the client-controlled object will be. Basically, the client performs the exact same object simulation as the server will eventually perform on that client's input data. As long as the client-controlled object is not acted upon by forces on the server that don't exist on the client or vice versa, the client and server state information for the object should perfectly agree. When they don't agree, interpolation can be employed to smoothly move the client object to the known server position and client-side prediction can be continued.
+
+
+Torque Network Library Archtectural Overview
+
+The Torque Network Library is built in layers, each adding more functionality to the layer below it.
+
+The Platform Layer
+
+At the lowest level, TNL provides a platform independent interface to operating system functions. The platform layer includes functions for querying system time, sleeping the current process and displaying alerts. The platform layer includes wrappers for all of the C standard library functions used in the TNL.
+
+The platform layer also contains the Socket and Address classes, which provide a cross-platform, simplified interface to datagram sockets and network addresses.
+
+The NetBase Layer
+
+The NetBase layer is the foundation upon which most of the classes in TNL are based. At the root of the class hierarchy is the Object base class. Every subclass of Object is associated with an instance of NetClassRep through a set of macros, allowing for instances of that class to be constructed by a class name string or by an automatically assigned class id.
+
+This id-based instantiation allows objects subclassed from NetEvent and NetObject to be serialized into data packets, transmitted, constructed on a remote host and deserialized.
+
+Object also has two helper template classes, SafePtr, which provides safe object pointers that become NULL when the referenced object is deleted, and a reference pointer class, RefPtr, that automatically deletes a referenced object when all the references to it are destructed.
+
+The BitStream and PacketStream classes
+
+The BitStream class presents a stream interface on top of a buffer of bytes. BitStream provides standard read and write functions for the various TNL basic data types, including integers, characters and floating point values. BitStream also allows fields to be written as bit-fields of specific size. An integer that is always between 3 and 9 inclusive can be written using only 3 bits using the writeRangedU32 method, for example.
+
+BitStream huffman encodes string data for additional space savings, and provides methods for compressing 3D points and normals, as routines for writing arbitrary buffers of bits.
+
+The PacketStream subclass of BitStream is simply a thin interface that statically allocates space up to the maximum size of a UDP packet. A routine can declare a stack allocated PacketStream instance, write data into it and send it to a remote address with just a few lines of code.
+
+The NetInterface and NetConnection Layer
+
+The NetInterface class wraps a platform Socket instance and manages the set of NetConnection instances that are communicating through that socket. NetInterface is manages the two-phase connection initiation process, dispatch of protocol packets to NetConnection objects, and provides a generic interface for subclasses to define and process their own unconnected datagram packets.
+
+The NetConnection class implements the connected Notify Protocol layered on UDP. NetConnection manages packet send rates, writes and decodes packet headers, and notifies subclasses when previously sent packets are known to be either received or dropped.
+
+NetInterface instances can be set to use a public/private key pair for creating secure connections. In order to prevent attackers from depleting server CPU resources, the NetItnerface issues a cryptographically difficult "client puzzle" to each host attempting to connect to the server. Client puzzles have the property that they can be made arbitrarily difficult for the client to solve, but whose solutions can be checked by the server in a trivial amount of time. This way, when a server is under attack from many connection attempts, it can increase the difficulty of the puzzle it issues to connecting clients.
+
+The ConnectionParameters structure maintains all of the information needed by the NetInterface to negotiate the startup phase of a NetConnection.
+
+The Event Layer - EventConnection, NetEvent and Remote Procedure Calls
+
+The EventConnection class subclasses NetConnection to provide several different types of data transmission policies. EventConnection uses the NetEvent class to encapsulate event data to be sent to remote hosts. Subclasses of NetEvent are responsible for serializing and deserializing themselves into BitStreams, as well as processing event data in the proper sequence.
+
+NetEvent subclasses can use one of three data guarantee policies. They can be declared as GuaranteedOrdered, for ordered, reliable message delivery; Guaranteed, for reliable but possibly out of order delivery, or Unguaranteed, for ordered but not guaranteed messaging. The EventConnection class uses the notify protocol to requeue dropped events for retransmission, and orders the invocations of the events' process methods if ordered processing is requested.
+
+Because declaring an individual NetEvent subclass for each type of message and payload to be sent over the network, with its corresponding pack, unpack and process routines, can be somewhat tedious, TNL provides a Remote Procedure Call (RPC) framework. Using some macro magic, argument list parsing and a little assembly language, methods in EventConnection subclasses can be declared as RPC methods. When called from C++, the methods construct an event containing the argument data passed to the function and send it to the remote host. When the event is unpacked and processed, the body of the RPC method implementation is executed.
+
+Ghosting - GhostConnection and NetObject
+
+The GhostConnection class subclasses EventConnection in order to provide the most-recent and partial object state data update policies. Instances of the NetObject class and its subclasses can be replicated over a connection from one host to another. The GhostConnection class manages the relationship between the original object, and its "ghost" on the client side of the connection.
+
+In order to best utilize the available bandwidth, the GhostConnection attempts to determine which objects are "interesting" to each client - and among those objects, which ones are most important. If an object is interesting to a client it is said to be "in scope" - for example, a visible enemy to a player in a first person shooter would be in scope.
+
+Each GhostConnection object maintains a NetObject instance called the scope object - responsible for determining which objects are in scope for that client. Before the GhostConnection writes ghost update information into each packet, it calls the scope object's performScopeQuery method which must determine which objects are "in scope" for that client.
+
+Each scoped object that needs to be updated is then prioritized based on the return value from the NetObject::getUpdatePriority() function, which by default returns a constant value. This function can be overridden by NetObject subclasses to take into account such factors as the object's distance from the camera, its velocity perpendicular to the view vector, its orientation relative to the view direction and more.
+
+Rather than always sending the full state of the object each time it is updated across the network, the TNL supports only sending portions of the object's state that have changed. To facilitate this, each NetObject can specify up to 32 independent states that can be modified individually. For example, a player object might have a movement state, detailing its position and velocity, a damage state, detailing its damage level and hit locations, and an animation state, signifying what animation, if any, the player is performing.
+
+A NetObject can notify the network system when one of its states has changed, allowing the GhostConnections that are ghosting that object to replicate the changed state to the clients for which that object is in scope.
+
+Encryption and TNL
+
+The TNL has hooks in various places to use encryption when requested. To enable encrypted connections, the NetInterface must be assigned an instance of AsymmetricKey as a public/private key pair using NetInterface::setPrivateKey. The NetInterface::setRequiresKeyExchange method may then be called to instruct the NetInterface that all incoming connection requests must include a key exchange.
+
+Asymmetric keys can be constructed with varying levels of security. The TNL uses Elliptic Curve public key crytpography, with key sizes ranging from 20 to 32 bytes. AsymmetricKey instances can be constructed either with a new, random key of a specified size, or can be created from an existing ByteBuffer.
+
+Once a secure connection handshake is completed, TNL uses the AES symmetric cipher to encode connected packets. The BitStream::hashAndEncrypt and BitStream::decryptAndCheckHash methods use an instance of SymmetricCipher to encrypt and decrypt packets using a shared session key.
+
+In order to have properly secure communications, the cryptographically strong pseudo-random number generator (PRNG) in TNL must be initialized with good (high entropy) random data.
+
+Useful Classes
+
+TNL uses a number of utility classes throughout. Some of these include:
+
+Vector - The Vector template class is a lightweight version of the STL Vector container.
+
+DataChunker - The DataChunker class performs small, very low overhead memory allocation out of a pool. Individual allocations cannot be freed, however the entire pool can be freed at once.
+
+ClassChunker - The ClassChunker template class uses the DataChunker to manage allocation and deallocation of instances of the specific class. ClassChunker maintains a free list for quick allocation and deallocation.
+
+StringTableEntry - StringTableEntry wraps a ref-counted element in the StringTable, with simple conversion operations to C strings. StringTableEntry instances can be sent in the parameter lists of RPC methods or using the EventConnection::packStringTableEntry method.
+
+ByteBuffer - The ByteBuffer class wraps a buffer of arbitray binary data. ByteBuffer serves as a base class for BitStream, as well as the cryptographic primitives.
+
+Debugging and Error Handling
+
+Correcting bugs in a networked simulation can sometimes be an incredibly difficult task. TNL provides some handy features to make debugging somewhat less challenging:
+
+Asserts - The TNLAssert and TNLAssertV macros specify a condition that, if false, will cause the application to display an error dialog and halt in the debugger where the assert was hit. Asserts are very useful for sanity-checking arguments to functions, and making sure network data is being properly read from and written to packets.
+
+Logging - TNL has a set of simple but effective facilities for logging status information. The TNLLogMessage and TNLLogMessageV macros allow the user to specify logging tokens with particular log messages. Logging of messages associated with a given token can be enabled or disabled using the TNLLogEnable macro. Also, the TNLLogBlock macro can be used to log multiple logprintf statements in a single test. Rather than log to a file or other destination, TNL applications must declare at least one instance of a sublclass of TNLLogConsumer. Every TNLLogConsumer instance receives all the logging messages that are currently enabled.
+
+Debugging object writes into packets - One of the most common errors programmers experience when using TNL is failing to properly match the NetEvent::pack and NetEvent::unpack or NetObject::packUpdate and NetObject::unpackUpdate routines. By default, if TNL_DEBUG is defined, the EventConnection and GhostConnection classes will write extra size information into the packet before each object's data are written. The ConnectionParameters::mDebugObjectSizes flag can be modified directly to further control this behavior.
+
+Simple Torque Network Library Tutorial: Hello World
+
+This simple tutorial walks the user through the creation of a very simple networked example program using the RPC functionality of the EventConnection class. This command-line program can be run in either client or server modes. As a client it will attempt to connect to a server at the specified address and send it a message every second. When the server receives a message from a client, it will respond back with a "Hello, World!" message.
+
+First, create a new source file, "simpleNet.cpp", containing the following lines to start:
+
+#include "tnl.h"
+#include "tnlEventConnection.h"
+#include "tnlNetInterface.h"
+#include "tnlRPC.h"
+#include
+
+bool gQuit = false; // a flag used when the client wants to quit.
+
+using namespace TNL; // make sure we can simply use the TNL classes.
+
+If the compiler complains of missing include files, be sure the "tnl" directory is in the include path.
+
+Next, create a custom subclass of EventConnection for the example program to communicate across, and declare the client-to-server and server-to-client RPC methods:
+
+class SimpleEventConnection : public EventConnection
+{
+ typedef EventConnection Parent;
+
+public:
+ // Let the network system know this is a valid network connection.
+ TNL_DECLARE_NETCONNECTION(SimpleEventConnection);
+
+ // declare the client to server message
+ TNL_DECLARE_RPC(rpcMessageClientToServer, (const char *theMessageString));
+
+ // declare the server to client message
+ TNL_DECLARE_RPC(rpcMessageServerToClient, (const char *theMessageString));
+};
+
+The first macro invoked, TNL_DECLARE_NETCONNECTION declares members necessary to make this class work as a connection in TNL. The RPC methods are then declared using the TNL_DECLARE_RPC macro. The first parameter to the macro is the name of the RPC method, which can be invoked like any other member function on the object. The second argument is a parenthesized argument list to the RPC. Although these functions are both declared to take only a single string, RPC method parameter lists can contain all the basic TNL types, as well as StringTableEntry, ByteBuffer and Vector objects.
+
+Next, define the implementation of the SimpleEventConnection class:
+
+TNL_IMPLEMENT_NETCONNECTION(SimpleEventConnection, NetClassGroupGame, true);
+
+TNL_IMPLEMENT_RPC(SimpleEventConnection, rpcMessageClientToServer, (const char *messageString),
+NetClassGroupGameMask, RPCGuaranteedOrdered, RPCDirClientToServer, 0)
+{
+ // display the message the client sent
+ printf("Got message from client: %s\n", messageString);
+ // send a hello world back to the client.
+ rpcMessageServerToClient("Hello, World!");
+}
+
+TNL_IMPLEMENT_RPC(SimpleEventConnection, rpcMessageServerToClient, (const char *messageString),
+NetClassGroupGameMask, RPCGuaranteedOrdered, RPCDirServerToClient, 0)
+{
+ // display the message the server sent
+ printf("Got a message from server: %s\n", messageString);
+
+ // once the client has heard back from the server, it should quit.
+ gQuit = true;
+}
+
+The TNL_IMPLEMENT_NETCONNECTION macro specifies two properties. The first, NetClassGroupGame declares that this connection traffics only in NetEvent, NetObject and RPC instances that have the NetClassGroupGame mask bit set in their implementations. The second property, as declared by the boolean true specifies that remote hosts can request a connection of type SimpleEventConnection from this process.
+
+The TNL_IMPLEMENT_RPC macro behaves like a standard function signature declaration, but with some important additions. The first three arguments, class name, method name and arguments are fairly self-explanatory. The fourth argument is the connection type mask, which specifies which types of connections the specified RPC can travel over. Since RPC's (unlike NetEvent and NetObject subclasses) are declared for only a single connection class, this mask should always be the mask associated with the connection type declared in TNL_IMPLEMENT_NETCONNECTION.
+
+The fifth argument to the macro specifies the guarantee type of the RPC, which can be one of RPCGuaranteedOrdered, RPCGuaranteed or RPCUnguaranteed. The sixth parameter is the direction the RPC is allowed to travel, which when specified can make an application more secure from attacks that modify packets in transit. The last argument is a version number, which can be specified so that older clients can still connect to servers offering newer RPCs.
+
+The function body of the RPC similar to any other function body with one important difference. When an RPC method is invoked, the function body code is executed on the remote side of the connection. So if the client calls the method rpcMessageClientToServer("Hello?"), the code for the body will execute on the server.
+
+Now that the connection class is defined, all that is left to do is create the main() function that will start up the instance as either a client or a server.
+
+int main(int argc, const char **argv)
+{
+ if(argc != 3)
+ {
+ printf("usage: simpletnltest <-server|-client> ");
+ return 1;
+ }
+ bool isClient = !strcmp(argv[1], "-client");
+
+ // convert the command-line address into TNL address form
+ Address cmdAddress(argv[2]);
+
+ RefPtr theNetInterface;
+ if(isClient)
+ {
+ Address bindAddress(IPProtocol, Address::Any, 0);
+
+ // create a new NetInterface bound to any interface, any port (0)
+ theNetInterface = new NetInterface(bindAddress);
+
+ // create a new SimpleEventConnection and tell it to connect to the
+ // server at cmdAddress.
+ SimpleEventConnection *newConnection = new SimpleEventConnection;
+ newConnection->connect(theNetInterface, cmdAddress);
+
+ // post an RPC, to be executed when the connection is established
+ newConnection->rpcMessageClientToServer("Hello??");
+ }
+ else
+ {
+ // create a server net interface, bound to the cmdAddress
+ theNetInterface = new NetInterface(cmdAddress);
+
+ // notify the NetInterface that it can allow connections
+ theNetInterface->setAllowsConnections(true);
+ }
+
+ // now just loop, processing incoming packets and sending outgoing packets
+ // until the global quit flag is set.
+ while(!gQuit)
+ {
+ theNetInterface->checkIncomingPackets();
+ theNetInterface->processConnections();
+ Platform::sleep(1);
+ }
+ return 0;
+}
+
+Once the code is written, use your compiler to build simpletnltest, making sure to link in the tnl library, along with whatever network libraries your platform requires (wsock32.lib on Windows, for example).
+
+To test the program, open up two console shells, and in the first, type:
+
+simpletnltest -server 127.0.0.1:28000
+
+This will create an instance of simpletnltest running as a server and bound to port 28000 on the local host machine. In the second window, run another instance as a client, set to connect to the server like this:
+
+simpletnltest -client 127.0.0.1:28000
+
+Once the client runs, the server display should read:
+
+Got a message from client: Hello?
+
+and the client window should read:
+
+Got a message from server: Hello, World!
+
+The server will continue to accept new connections from clients until it is terminated manually.
+
+For an example program that uses more of TNL's advanced features, including RPCs with bit compressed arguments, a custom NetInterface subclass, and the NetObject replication system, look at the TNLTest project and documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/tnl-1.5.0/tnl/docs/doxygen.html.cfg b/tnl-1.5.0/tnl/docs/doxygen.html.cfg
new file mode 100644
index 0000000000000000000000000000000000000000..11faf98ef2954c5ff4b2f05c06d4cae52e0e16c6
--- /dev/null
+++ b/tnl-1.5.0/tnl/docs/doxygen.html.cfg
@@ -0,0 +1,216 @@
+# Doxyfile 1.3-rc2
+#---------------------------------------------------------------------------
+# General configuration options
+#---------------------------------------------------------------------------
+PROJECT_NAME = TNL
+PROJECT_NUMBER = 1.1.2
+OUTPUT_DIRECTORY = ./docs
+OUTPUT_LANGUAGE = English
+EXTRACT_ALL = YES
+EXTRACT_PRIVATE = YES
+EXTRACT_STATIC = YES
+EXTRACT_LOCAL_CLASSES = YES
+HIDE_UNDOC_MEMBERS = NO
+HIDE_UNDOC_CLASSES = NO
+HIDE_FRIEND_COMPOUNDS = NO
+HIDE_IN_BODY_DOCS = NO
+BRIEF_MEMBER_DESC = YES
+REPEAT_BRIEF = YES
+ALWAYS_DETAILED_SEC = NO
+INLINE_INHERITED_MEMB = NO
+FULL_PATH_NAMES = NO
+STRIP_FROM_PATH =
+INTERNAL_DOCS = NO
+CASE_SENSE_NAMES = YES
+SHORT_NAMES = NO
+HIDE_SCOPE_NAMES = NO
+VERBATIM_HEADERS = NO
+SHOW_INCLUDE_FILES = YES
+JAVADOC_AUTOBRIEF = YES
+MULTILINE_CPP_IS_BRIEF = NO
+DETAILS_AT_TOP = YES
+INHERIT_DOCS = YES
+INLINE_INFO = YES
+SORT_MEMBER_DOCS = NO
+DISTRIBUTE_GROUP_DOC = NO
+TAB_SIZE = 4
+GENERATE_TODOLIST = YES
+GENERATE_TESTLIST = YES
+GENERATE_BUGLIST = YES
+GENERATE_DEPRECATEDLIST= YES
+ALIASES =
+ENABLED_SECTIONS =
+MAX_INITIALIZER_LINES = 30
+OPTIMIZE_OUTPUT_FOR_C = YES
+OPTIMIZE_OUTPUT_JAVA = NO
+SHOW_USED_FILES = NO
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+QUIET = NO
+WARNINGS = YES
+WARN_IF_UNDOCUMENTED = NO
+WARN_IF_DOC_ERROR = YES
+WARN_FORMAT = "$file:$line: $text"
+WARN_LOGFILE = doxygen.log
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+INPUT = ./tnl/tnl.overview.txt \
+ ./tnl/tnl.changelog.txt \
+ ./tnl/ \
+ ./master/ \
+ ./test/ \
+ ./zap/ \
+
+FILE_PATTERNS = *.h \
+ *.txt
+RECURSIVE = YES
+EXCLUDE = */cvs/* \
+ */platformMacCarb/* \
+ */platformX86UNIX/*
+EXCLUDE_SYMLINKS = NO
+EXCLUDE_PATTERNS =
+EXAMPLE_PATH =
+EXAMPLE_PATTERNS =
+EXAMPLE_RECURSIVE = NO
+IMAGE_PATH =
+INPUT_FILTER =
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+SOURCE_BROWSER = NO
+INLINE_SOURCES = NO
+STRIP_CODE_COMMENTS = NO
+REFERENCED_BY_RELATION = YES
+REFERENCES_RELATION = YES
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+ALPHABETICAL_INDEX = NO
+COLS_IN_ALPHA_INDEX = 5
+IGNORE_PREFIX =
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+GENERATE_HTML = YES
+HTML_OUTPUT = doxydocs
+HTML_FILE_EXTENSION = .html
+HTML_HEADER = ./docs/header.html
+HTML_FOOTER = ./docs/footer.html
+HTML_STYLESHEET = ./docs/doco.css
+HTML_ALIGN_MEMBERS = YES
+GENERATE_HTMLHELP = NO
+CHM_FILE = tnl.chm
+HHC_LOCATION = .
+GENERATE_CHI = NO
+BINARY_TOC = NO
+TOC_EXPAND = NO
+DISABLE_INDEX = YES
+ENUM_VALUES_PER_LINE = 1
+GENERATE_TREEVIEW = NO
+TREEVIEW_WIDTH = 250
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+GENERATE_LATEX = NO
+LATEX_OUTPUT = pdf
+LATEX_CMD_NAME = latex
+MAKEINDEX_CMD_NAME = makeindex
+COMPACT_LATEX = NO
+PAPER_TYPE = a4wide
+EXTRA_PACKAGES =
+LATEX_HEADER =
+PDF_HYPERLINKS = YES
+USE_PDFLATEX = YES
+LATEX_BATCHMODE = NO
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+GENERATE_RTF = NO
+RTF_OUTPUT = rtf
+COMPACT_RTF = YES
+RTF_HYPERLINKS = YES
+RTF_STYLESHEET_FILE =
+RTF_EXTENSIONS_FILE =
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+GENERATE_MAN = NO
+MAN_OUTPUT = man
+MAN_EXTENSION = .3
+MAN_LINKS = NO
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+GENERATE_XML = NO
+XML_SCHEMA =
+XML_DTD =
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+GENERATE_AUTOGEN_DEF = NO
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+GENERATE_PERLMOD = NO
+PERLMOD_LATEX = NO
+PERLMOD_PRETTY = YES
+PERLMOD_MAKEVAR_PREFIX =
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+ENABLE_PREPROCESSING = YES
+MACRO_EXPANSION = YES
+EXPAND_ONLY_PREDEF = YES
+SEARCH_INCLUDES = YES
+INCLUDE_PATH = ./tnl/
+INCLUDE_FILE_PATTERNS =
+PREDEFINED = DOXYGENIZING \
+ TNL_DEBUG \
+ TNL_ENABLE_ASSERTS \
+ TNL_ENABLE_LOGGING
+
+EXPAND_AS_DEFINED = DeclareTemplatizedReadWrite
+
+SKIP_FUNCTION_MACROS = NO
+#---------------------------------------------------------------------------
+# Configuration::addtions related to external references
+#---------------------------------------------------------------------------
+TAGFILES =
+GENERATE_TAGFILE =
+ALLEXTERNALS = NO
+EXTERNAL_GROUPS = YES
+PERL_PATH = /usr/bin/perl
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+CLASS_DIAGRAMS = YES
+HIDE_UNDOC_RELATIONS = NO
+HAVE_DOT = NO
+CLASS_GRAPH = YES
+COLLABORATION_GRAPH = NO
+TEMPLATE_RELATIONS = YES
+INCLUDE_GRAPH = NO
+INCLUDED_BY_GRAPH = NO
+GRAPHICAL_HIERARCHY = YES
+DOT_IMAGE_FORMAT = png
+DOT_PATH = "/cygdrive/c/Progra~1/ATT/Graphviz/bin"
+DOTFILE_DIRS =
+MAX_DOT_GRAPH_WIDTH = 1024
+MAX_DOT_GRAPH_HEIGHT = 1024
+MAX_DOT_GRAPH_DEPTH = 4
+GENERATE_LEGEND = YES
+DOT_CLEANUP = NO
+#---------------------------------------------------------------------------
+# Configuration::addtions related to the search engine
+#---------------------------------------------------------------------------
+SEARCHENGINE = NO
+CGI_NAME = search.cgi
+CGI_URL =
+DOC_URL =
+DOC_ABSPATH =
+BIN_ABSPATH = /usr/local/bin/
+EXT_DOC_PATHS =
diff --git a/tnl-1.5.0/tnl/docs/footer.html b/tnl-1.5.0/tnl/docs/footer.html
new file mode 100644
index 0000000000000000000000000000000000000000..69e967af1aa4d080bfb68e8c46cc538e065d81de
--- /dev/null
+++ b/tnl-1.5.0/tnl/docs/footer.html
@@ -0,0 +1,10 @@
+
+
+
+
+
+