Joel Peach

Bhavin,
Implementing internet standard protocols (HTTP, FTP, NNTP, etc) is redundant, but probably the most practical and a great way to learn.
TFTP might be easier to implement than FTP since it has a smaller set of commands.
You might also try implementing an SMTP mail server without relying on the JavaMail API.
If you pick such a project you are likely to find more technical resources (newsgroups, people, etc.) at your disposal.
Best of Luck!
-Joel

Nouman,
Before you get going, be sure to check out Jabber at http://www.jabber.org . It's an open standard for messaging that includes a gateway architecture that allows you to talk to different IM services.
You should find links to tons of source code for the clients and servers, many written in Java.
Best of luck!
-Joel

Someone should really write a component to do this. There are actually many more numeric representations that are allowed for specifying IP addresses, including different bases (octal, hex, etc).
See the following site for more information on the alternate IP address representations.
http://www.pc-help.org/obscure.htm
Best of luck!
-Joel

If you're interested in current security events, I highly suggest going to http://www.counterpane.com and subscribing to the Crypt-o-gram newsletter. It is published on the 15th of every month and includes insights and a wrapup of recent computer security events. It is written by Bruce Schneier, who penned "Applied Cryptography", the bible of computer cryptography. He also has a terrific book out called "Secrets and Lies".
Another contemporary of Bruce Schneier's is Ross Anderson.
http://srd.yahoo.com/goo/ross+anderson+crypto/1/*http://www.cl.cam.ac.uk/~rja14/
Ross Anderson wrote "Security Engineering" published by Addison Wesley. This book is a comprehensive collection of his lecture notes on security at the University of Cambridge. It is far and away the best, most complete book on security issues that I have ever read. If you start your journey here, your online search will be much more fruitful.
Best of luck!
-Joel

Just an additional note. Using the JDK facilities you won't be able to create an IP packet directly. The JDK operates at a much higher level and allows you to get an output stream and write to it, from which IP packets are created, but they're out of your direct reach.
Best of luck!
-Joel

Alex,
SO_TIMEOUT also applies to serversockets when you want to set the max time for an accept() call. I couldn't find any additional information on native support for what you're trying to do in the JDK docs.
Best of luck!
-J

Yash,
For information on Java support, check out the following JavaSoft tutorial:
http://java.sun.com/docs/books/tutorial/networking/datagrams/broadcasting.html
You might find that the support for broadcast/multicast is easier than you think.
Best of luck!
-Joel

Michael,
Undertaking a Java project can be a piece of cake, or it can be a several year long effort that consumes the resources of thousands of dollars and person-hours.
Part of what you should consider in evaluating the project is your experience that is like the experience that will be necessary. For example, consider:

How much experience do you or your resources have doing a migration/systems integration project?

How much experience do you have coding Model View Controller client GUI applications?

How much experience do you have designing client/server applications?

How much experience do you have writing web applications (ASP, COM, VB, C++) etc.
Once you've considered these questions, then I think you'll be in a better position to assess the cost of taking on such an initiative in Java. Many of Java facilities and features are a piece of cake to program in and very similar to C++/VB/Microsoft analogs. Some Java techniques are complicated, like CORBA, JNI. All have a learning curve, however, and your best way to get a taste for that is to pick up an introductory book on Java and get programming.
<shameless plug>
I know Wrox publishes a book by Ivor Horton called, "Beginning Java 2 - Jdk 1.3 Edition".
http://www.amazon.com/exec/obidos/ASIN/1861003668/
It is very comprehensive and available at nearly every book outlet. This book will give you a great overview taste of the language.
</shameless plug>
Once you're comfortable with the language, you might move on to other books that discuss the specific implementation technologies such as RMI, JSP/Servlets, J2EE.
Best of luck!
-Joel
[This message has been edited by Joel Peach (edited December 11, 2001).]

Thanks Rick,
You are correct, there is no direct FTP protocol support class in java. All of the basic components you need are there: Threading, Socket I/O, File I/O, but you'd still need to write the control logic on your own. If you're feeling ambitious, the IETF RFC specification that defines FTP can be found at:
http://www.faqs.org/rfcs/rfc959.html
A search on SourceForge (http://sourceforge.net/) revealed a couple of open source FTP library projects that may be of use. If you're writing a server application, you might want to check out the Jakarta "Avalon" subproject which is an open source project that provides many basic components that are useful to write servers. You can find out more at:
http://jakarta.apache.org/avalon/index.html
Best of luck!
-Joel
[This message has been edited by Joel Peach (edited December 11, 2001).]

Dennis,
This is absolutely the case! FTP employs two connections, a "control" connection which is the one that you have opened up. This is the initial connection used to send commands between the client and sever. The second connection is the "data" connection which, as the name implies, is where the data is piped.
If you haven't already, check out RFC 959
http://www.faqs.org/rfcs/rfc959.html
This is the FTP standard specification that will explain in detail (but is still quite readable for an RFC) how the FTP model functions.
Best of luck!
-Joel

Kyle,
I'm not familiar with the exact protocol, but I know the folks at IBM were doing a lot of work with autonomous internet agents. IBM also does a ton of Java work, so you may want to poke around Developerworks and see what you find.
http://www.ibm.com/developerworks/
Best of Luck!
-Joel

Kyle,
The approach you've taken is probably the most clean and practical. What you've done is basically introduce the idea of a timeout into your distributed object interaction. You should check the documentation with your ORB, as I believe many provide a timeout setting for just this purpose.
Do you have this problem with your C++ server when you use a client that isn't Java. If so, and if possible, you might try investing some time to see what's going wrong in the C++ server.
Best of luck!
-Joel

Glad to be here also.
In response to your question Tom, RMI and CORBA (and EJB and .NET, for that matter) are all about having options for remote/distributed computing.
RMI is of particular benefit because it exists right out of the box with the JDK. You get this distributed object framework for free, including the RMI registry which is used to do lookups. RMI takes care of virtually all the low-level networking headaches and together with the serialization facilities of Java allows you to send entire objects back and forth on the wire. The major downside to native RMI is that the object implementations need to be in Java. RMI over IIOP, however, lets rmi servers and clients communicate over the same protocol as CORBA objects.
CORBA provides more functionality over RMI. More than just a distributed object framework, CORBA begins providing additional services that are of value such as security and transaction management. These make it so that CORBA developers can leverage the benefit of distributed transactions without the headaches of implementing a transaction service. The other service implementations are meant to provide this ease of use. It would be possible to implement such services on top of RMI, but it isn't supported natively. Another nice thing about CORBA is that the interfaces are defined in a form that isn't platform or technology specific. Bindings are provided for each supported language (C, C++, Java, Python, and many other among them) so that servers and clients can be written in entirely different languages.
EJB builds upon the idea of RMI (distributed objects) and CORBA (easily available services) and tries to add the benefit of ease of persistence for objects. The whole idea is that now all of your objects run in a managed environment (container) that provides you a wealth of services including Container Managed Persistence, which even in its latest release, hasn't met all of its promises. Nonetheless, EJB is a stable, robust platform for creating distributed applications and can be a great deal easier to code than RMI and CORBA at times.
That's my whirlwind tour on the tradeoffs for these technologies. I didn't write the RMI or CORBA chapters, so perhaps some of the other guys will have some additional ideas. And if there's any specific point of comparison you'd like my take on, just ask!
Cheers,
-Joel

Sanjay,
I didn't find anything in the JavaMail spec about mailing from behind a proxy. I.e., I don't believe there's native support for mailing through a proxy, but you might be able to do it with some of the Transport/Message implementations.
In my experience with proxy software (Wingate), in order to make use of the software, you had to specify the email host in a special way (I think it was delimited with a # sign). I haven't tried, but that may work with JavaMail.
This same question was posted to jGuru, but the reply wasn't particularly helpful:
http://www.jguru.com/faq/view.jsp?EID=21068
Best of Luck!
-Joel

There is an SSL howto if you're asking how to enable SSL on the Apache server itself. It can be accessed at:
http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html
Best of luck!
-Joel
jpeach@traceris.com