FAQ: JAVA-Networking
VER: 0.6 (12 DEC 96)
LOC:
http://www.io.com/~maus/JavaNetworkingFAQ.html
Written by James Driscoll (maus@io.com) Aug 11th 1996.
Please e-mail me corrections/improvements/suggestions.
"Java is a trademark of Sun Microsystems, Inc., and refers to Sun's Java programming language. The Java Networking FAQ is not sponsored by or affiliated with Sun Microsystems, Inc."
You are free to distribute this FAQ as long as this section is distributed "as is" along with it. This document is Copyright 1996 by James Driscoll
Please direct any questions to me (Jim Driscoll) maus@io.com
I stand on the shoulders of giants, as all FAQ maintainers do. I would especially like to thank the following people for their help and guidance in the preparation of this document.
Ronald Tschalaer, Ronald.Tschalaer@psi.ch
David Brown, David.A.Brown@Eng.Sun.COM
Bob Pasker, rbp@weblogic.com
Pavani Diwanji, pavani@Eng.Sun.COM
All errors are of course my own.
I created this FAQ because I felt that existing FAQs did not address many network related issues. I hope that this document can be a resource for everyone who would like to fully utilize the java.net.* classes.
More than likely, the problem is that you are using the version of showDocument with one parameter.
This version calls a new page on the browser, which unloads the current page. This leads to two problems:
First, the stop() method of your applet is called (no big deal but be aware of it). Second (and more seriously),
the AppletContext is no longer valid. The way to get around this is through the use of HTML frames. Create
a separate frame for the applet. You can then use the version of showDocument that has two arguments:
getAppletContext().showDocument(new URL("http://www.mysite.com"), "otherframe");
Optionally, you could call up a new web browser window with the following:
getAppletContext().showDocument(new URL("http://www.yahoo.com"), "_blank");
No. If you can't write to your server, you can't save the information on the current count. Your only option is CGI. Sorry.
I find the telnet command to be an invaluable aid in debugging server processes. To use telnet to do this, enter the command
telnet host portWhere host is the hostname or IP of the machine the server is running on (localhost or 127.0.0.1 for local), and port is the port number that the server is listening on. For example, to open up a whole new world of email from Santa Claus, try telnetting to your mailhost at port 25 (the SMTP port).
No. You will have to implement some sort of control on the server side to allow that, using CGI.
Yes. Java sockets use the IP protocols TCP and UDP. These are standard internet sockets, and will work with any sockets that also use TCP and UDP. You've just discovered why people get so excited talking about "open systems". I recommend that you pick up Stevens' book (in the bibliography) for an in depth look at how they work.
More than likely, you are running under Unix, and trying to open a server socket with a port number <1024. Try a port number >1024, or run your server as root.
The easiest answer is "it's been done".
Implementations of these classes are shipped with Sun's Java class library (check under sun.net), but they are non-standard API's. They do work, and work well - but Javasoft reserves the right to change them at any time, without warning. They are also undocumented... You can, however, find javadoc built documentation at http://www.cdt.luth.se/java/doc/sun/. Finally, keep in mind that your end user does not necessarily have access to them, as they are only shipped to Java licensees. Apparently, Microsoft Internet Explorer 3.0 contains these libraries, while Netscape 3.0 does not.
Additionally, many people have also had this idea before you: check Gamelan or your favorite search engine for existing code before you start writing. SMTP, at least, has been beaten to death.
Implementations of these already exist. Check gamelan or your favorite search site to find them.
There is a beta SSL class available from http://www.phaos.com/ Netscape says they'll include an SSL class in Netscape 4.0. JavaSoft is working on one in conjunction with the Java Server project.
This one is easy. Just build a URL with the query string on the
end in the usual way. i.e. http://www.site.com/perl-script.pl?val1=Put+stuff+here
.
java.net.URLEncode.encode() is a static method that will properly encode a string for you, as well.
Optionally, you could perform an java.applet.AppletContext.showDocument(), which also will submit the
information, using the browser to display the output.
[Note: Write sample code for here]
[Note: This is a fairly complex question, a complete rewrite of this section is in the works]
Performing a POST operation in Java using a URLConnection is a little more complicated than most other tasks. First, Netscape disabled posting via URLConnection in the beta versions of 3.0. It has been reenabled in 3.0. The description below should work for Netscape 3.0, Internet Explorer 3.0, and applications. [Note: tests still need to be done by me to ensure this is so.]
When connecting with URLConnection to a URL formed with the http: protocol, the
HttpURLConnection class is called. This class determines whether the connection is to be made
with a GET or a POST by watching the order in which output and input streams are created. The following
comment is from the source code, and I beleive is quite clear:
/*
* Allowable input/output sequences:
* [interpreted as POST]
* - get output, [write output,] get input, [read input]
* - get output, [write output]
* [interpreted as GET]
* - get input, [read input]
* Disallowed:
* - get input, [read input,] get output, [write output]
*/
Additionally, in Navigator, appletviewer/Hotjava and all other standalone java-apps as of Java 1.1, you must also setDoOutput(true) on the URLConnection object before getting the output stream.
[Note: add working code snip here.]
[Note: add discussion of URLConnection and Proxies.]
[Note: add section on writing files to the server, and HTTP PUT]
Ping requires ICMP packets. These packets can only be created via a socket of the SOCK_RAW type. Currently, Java only allows SOCK_STREAM (TCP) and SOCK_DGRAM (UDP) sockets. It seems unlikely that this will be added very soon, since many Unix versions only allow SOCK_RAW sockets to be created by root, and winsock does not address ICMP packets (win32 includes an unsupported and undocumented ICMP.DLL).
For a full discussion of socket types, see Stevens' book (in the bibliography).
If you are running Windows 95, this is a known bug that was fixed in Java version 1.02. Pick up the latest version of the software, it should fix it for you.
This is a bug in Windows 95. Resources are not properly reclaimed when a socket is closed. See the microsoft web site for a patch. (http://www.microsoft.com/)
Only on some machines. This is one of those annoying platform differences that can apparently be traced back to the basic networking libraries on each machine. There will be a patch in the 1.1 release for this behavior. See http://www.cdt.luth.se/~peppar/java/InetAddress/ for one solution to this.
The example code we are discussing is:
Socket sock = new Socket("155.152.5.1", 23);
On Solaris and Windows NT, the IP address does not work for IP addresses that do not have associated hostnames. On Linux and Windows 95, the IP address is OK. [Note: Here I am merely repeating things that I've read on USENET. Independent confirmation of this would be appreciated.]
This is apparently related with problems in the InetAddress class. When InetAddress is
instantiated with an IP address, a reverse DNS lookup is done. If the IP address is not
associated with a valid hostname, the instantiation will fail. This is part of anti-spoofing,
and will be relaxed in Java 1.1. In the new version, the reverse lookup will not occur
until the hostname is asked for. In Java 1.1,
InetAddress in = InetAddress.getByName("155.152.5.1");
should always work.
Returning the fully qualified hostname is not guarenteed. Currently, whether this series of calls does or not is platform dependant. On Solaris, it will return only the unqualified host name. On Windows, it may return the fully qualified name, or it may not. It will depend on the version of Winsock in use. If you are using the Microsoft Winsock, you will get the fully qualified name. The 1.1 FCS JDK should have a fix for the Solaris part of this problem, anyway.
In both Netscape and Microsoft Internet Explorer, the security manager is both very restrictive and not subject to configuration. Applets are only allowed to create sockets back to the same server that they came from. While this is probably overkill for the home user, there is a very good reason for this policy: Firewalls. In the corporate world, most Internet security is established through the use of firewalls, which restrict incoming connection requests. A Java applet that could connect anywhere could establish a link that allowed hacker.org to telnet in to payroll.largecomp.com. Since even HTTP-GET connections can pass along sensitive information (http://www.hacker.org/dummy.cgi?Bob+has+no+password), all connections have to be restricted. The security manager will be configurable in Netscape 4.0, due out at the end of the year (maybe), and this may be one of the configurable options. For a good discussion of applet security issues, see http://www.innovation.ch/java/HTTPClient/security.html
Apparently, there are no content handlers defined in the Java spec. [Note: I need to check on this. I found no reference in the API reference.] The JDK from sun provides Content handlers as Java's way to add functionality to the URL class. By adding content handlers, the URL class can be made to return various MIME types as objects with the getContent method. With the proper content handlers in place, downloading GIFs, JPEGs, MPEGs, and Postscript documents, to name a few, is just a single method call.
Protocol handler are another way to extend the URL class. Again, there are no standard protocol handlers defined in the Java spec. [Note: Again, I find that I have to get Gosling's book to check this.] In a URL, the protocol is the first part of the URL string, the part that preceeds the colon. With the proper protocol handlers in place, URLs can handle ftp, mail, gopher, and even finger. Check out http://java.sun.com/people/brown/ for an implementation of a finger protocol handler.
Netscape apparently supports the ftp:, mailto:, gopher:, and even the telnet: content handlers (I couldn't find anywhere this was documented). As near as I can tell, noone else does at this time. As a result, you may wish to use this sparingly. It is very easy to test at runtime for content handler support, however. Simply create a URL using the protocol handler.
URL testurl; boolean goodmailto; try { testurl = new URL("mailto:maus@io.com"); goodmailto = true; } catch (MalformedURLException e) { goodmailto = false; }
In this example, goodmailto will be true if the protocol handler exists, and false if it does not. [Note: Include link to sample applet at my site which does this.]
[Note: Does anyone know where the documentation is for using these non-http content handlers?]
The best answer to that is - "It depends". If you intend to write client-side CGI handling in Java, the mechanisms for it are there and easy to use (see CGI-POST and CGI-GET questions above). If you would like to write CGI server-side programs, be aware that Java has no defined way to grab the enviroment variables that you will need from the HTTP server. JavaSoft has introduced the Servlet API as a standard way to do this, but adoption of this standard by the major server players is still somewhat distant.
If you do not have access to a server with a Java API for CGI, you will have to write a shell wrapper for your Java programs, since Java has no way of obtaining enviroment variables. Examples exist on the web, if you need guidance.
Glad you asked! Yes, there are lots of exciting things happening in Java 1.1. Please see http://www.javasoft.com/products/JDK/1.1/designspecs/net/index.html for proposed changes, due late this year.
General information on changes to the Java Language can be found at http://www.javasoft.com/products/JDK/1.1/designspecs/index.html.
Unix Network Programming by W. Richard Stevens
Published by PRENTICE HALL
Publication date: 1990
ISBN: 0139498761
Note: While this book does not cover Java network programming, it is considered the
definitive reference for BSD socket programming in general.
Just Java by Peter Van Der Linden
Published by PRENTICE HALL COMPUTER BOOKS
ISBN: 013565839X
Core Java by Gary Cornell , Cay S. Horstmann
Published by PRENTICE HALL COMPUTER BOOKS
Publication date: April 1, 1996
ISBN: 0135657555
The Java Application Programming Interface (Java Series) by James
Gosling , Frank Yellin
Volume 1
Published by ADDISON-WESLEY PUB CO
ISBN: 0201634538
Java in a Nutshell : A Desktop Quick Reference for Java Programmers
(Nutshell Handbook) by David Flanagan
Published by O'REILLY & ASSOC
ISBN: 1565921836
Java Networking Api Superbible : The Comprehensive Reference for
the Java Programming Language
by Nataraj Nagaratnam , Brian Maso , Arvind Srinivasan
Published by WAITE GROUP PR
ISBN: 157169031X