resolve
[org.ibex.jinetd.git] / www / index.html
1 <html>
2 <body>
3
4 <h1>Jinetd: inetd for Java</h1>
5
6 <h3> What is it? </h3>
7
8 Jinetd does for TCP what servlet containers do for HTTP.
9
10 <h3> Isn't HTTP all that matters? </h3>
11
12 There are now Java servers for almost every network protocol: HTTP,
13 SMTP, IMAP, POP3, NNTP, DNS, SSH, CIFS/SMB, and plenty of others.
14 Using servers written in buffer-overflow-free languages is the most
15 important step towards maintaining network security and stopping
16 worms.
17
18 <h3> Huh? </h3>
19
20 Jinetd listens on the ports and interfaces you specify.  When it
21 receives a connection, it loads the code designated to handle that
22 protocol and hands off the connection.
23
24 <h3> Isn't that trivially simple? </h3>
25
26 While jinetd is an extremely lightweight server, it allows multiple
27 different network protocol handlers to share the following facilities:
28
29 <ul><li> No need for "start", "stop", or "reload" commands:
30     <ul>
31         <li> Automatic reloading of services when a .jar, .class, or
32              .java file changes; just drop in the new code or
33              <tt>touch</tt> the jar file to trigger a restart.
34
35         <li> Services can add their own configuration files to the
36              "watched" list.
37
38         <li> Connections are always accepted immediately, even if the
39              service's code is still initializing itself.  The
40              connection is paused until the service finishes loading,
41              at which point it is handled.  No more "503 Server
42              Unavailable" messages for your users when you restart a
43              context; the user just experiences a brief delay before
44              the webpage loads.
45     </ul>
46
47     <li> Edit-in-place development
48     <ul>
49         <li> Automatic compilation of .java files for a service;
50              automatic reload once compilation completes
51     </ul>
52
53     <li> Self-restart
54     <ul>
55         <li> jinetd is usually invoked from a "respawn" line in /etc/inittab
56
57         <li> when it detects that its .jar files have been modified,
58              it exits and lets init respawn it
59
60         <li> when resources run critically low (ie low memory), jinetd
61              will abort the JVM and let init respawn it -- the only
62              way to kill runaway threads in Java.
63     </ul>
64
65     <li> No configuration files to edit -- host-to-service and
66          port-to-service mappings are inferred from directory layout.
67
68     <li> Shared virtual host settings
69     <ul>
70     <li> Arrange your content by (virtual) host rather than by service
71          -- for example, the HTTP and NNTP content for
72          "www.megacz.com" are kept side by side in
73          "/jinetd/host/com/megacz/HTTP" and
74          "/jinetd/host/com/megacz/NNTP".
75     </ul>
76
77 </ul>
78
79 </body>
80 </html>
81 v v v v v v v
82 *************
83 <h1>Jinetd: inetd for Java</h1>
84
85 <h3> What is it? </h3>
86
87 Jinetd does for TCP what servlet containers do for HTTP.
88
89 <h3> Isn't HTTP all that matters? </h3>
90
91 There are now Java servers for almost every network protocol: HTTP,
92 SMTP, IMAP, POP3, NNTP, DNS, <a
93 href=http://www.jcraft.com/jsch/>SSH</a>, <a
94 href=http://telnetd.sourceforge.net/index.html>TELNET</a>, CIFS/SMB,
95 and plenty of others.  Using servers written in buffer-overflow-free
96 languages is the most important step towards maintaining network
97 security and stopping worms.
98
99 <h3> Huh? </h3>
100
101 Jinetd listens on the ports and interfaces you specify.  When it
102 receives a connection, it loads the code designated to handle that
103 protocol and hands off the connection.
104
105 <h3> Isn't that trivially simple? </h3>
106
107 While jinetd is an extremely lightweight server, it allows multiple
108 different network protocol handlers to share the following facilities:
109
110 <ul><li> No need for "start", "stop", or "reload" commands:
111     <ul>
112         <li> Automatic reloading of services when a .jar, .class, or
113              .java file changes; just drop in the new code or
114              <tt>touch</tt> the jar file to trigger a restart.
115
116         <li> Services can add their own configuration files to the
117              "watched" list.
118
119         <li> Connections are always accepted immediately, even if the
120              service's code is still initializing itself.  The
121              connection is paused until the service finishes loading,
122              at which point it is handled.  No more "503 Server
123              Unavailable" messages for your users when you restart a
124              context; the user just experiences a brief delay before
125              the webpage loads.
126     </ul>
127
128     <li> Edit-in-place development
129     <ul>
130         <li> Automatic compilation of .java files for a service;
131              automatic reload once compilation completes
132     </ul>
133
134     <li> Self-restart
135     <ul>
136         <li> jinetd is usually invoked from a "respawn" line in /etc/inittab
137
138         <li> when it detects that its .jar files have been modified,
139              it exits and lets init respawn it
140
141         <li> when resources run critically low (ie low memory), jinetd
142              will abort the JVM and let init respawn it -- the only
143              way to kill runaway threads in Java.
144     </ul>
145
146     <li> No configuration files to edit -- host-to-service and
147          port-to-service mappings are inferred from directory layout.
148
149     <li> Shared virtual host settings
150     <ul>
151     <li> Arrange your content by (virtual) host rather than by service
152          -- for example, the HTTP and NNTP content for
153          "www.megacz.com" are kept side by side in
154          "/jinetd/host/com/megacz/HTTP" and
155          "/jinetd/host/com/megacz/NNTP".
156     </ul>
157
158 </ul>
159
160 </body>
161 </html>
162
163 ^ ^ ^ ^ ^ ^ ^