To introduce myself to all you seasoned Java hands: I am an experienced programmer but new to Java, and my SCJD assignment will be my first experience of network programming. I have just downloaded the instructions to my SCJD assignment. (I take it, then, that this is the "new exam".) Suppose I decide to use sockets rather than the apparently more complex RMI. How do I find out an appropriate port number to use? (I will be testing on windows 98.) I suppose that the port number is something to be read from suncertify.properties once it's set up? OK then, how should I advise the examiner running the server process for the first time what port number to put in? (Yes I know that I must provide a way for the examiner to do this using the GUI.)
I think RMI is much simpler than sockets. You can call methods on a remote object just like it were a local object. With sockets, you'll need to do all the hard work yourself of inventing a protocol for your messages, then interpreting it at either end and doing the appropriate thing. Try the RMI tutorial on the Sun site and you'll see how easy it is. If you are set on sockets, why not just pick an arbitrary high port number to use and don't change it unless the user specifically says to use a special port. [ May 08, 2003: Message edited by: Perry Board ]
Richard, Welcome to Javaranch, and welcome to Java. I know what it is like to being an expert in one language then going to a different language and being a little overwhelmed. Actually that is my feelings right now, as I am learning Oracle Forms. There are areas that I think are difficult, and when I actually start to study and try them, I find that they are easy. But then there are the areas I think will be easy, and they tend to be harder. But my point is unless you try it you won't realize how easy it might actually be. RMI is easy in this case, even though it my look hard. I still think you should examine Sockets, as learning them too is valuable. As far as Port numbers go, Sockets and RMI allow you to pick the port number, if you wish. They also have default port numbers. Just accept whichever port number the assessor enters in the GUI. One of the major goals fo rthe assignment is writing flexible code. Good Luck, and keep posting questions and we will all help you as best as we can.
Thank you for the suggestion to use RMI. I downloaded Sun's tutorial on RMI, to find out that Sun's method entails setting up an HTTP server and a security manager (which you must not use in the SCJD assignment). So unless there is something I've missed, I think I'll stick to sockets. By all means point me at an RMI tutorial which shows me the benefits of RMI without the need of an HTTP server or a security manager. As for the point that, if I don't use RMI, I must work out an ad-hoc protocol to transfer info: I must implement a stand-alone mode where there is no object serialisation. So I must work out an ad-hoc protocol to transfer info *anyway*, so what's the extra difficulty with sockets?
Hi Richard, Using sockets is a valid choice - Sun say so explicitly in their assignment. However I think there are some things you are misunderstanding, so the following will try and explain a few things so you can make your choice with the right facts.
Sun's method entails setting up an HTTP server
Not sure which tutorial you downloaded. RMI can use a HTTP server, but it is not required. This thread has some links to other tutorials at Sun, which from memory do not require a web server or a security manager. Java comes with it's own RMI Registry program (called rmiregistry ) which you can use. Even better - you do not have to start an external program to use it ... you can start it programatically within your own application. And although it defaults to listening on port 1099, this is just a default - you can change that programatiically as well.
Sun's method entails setting up .... a security manager
There is no need for a security manager for this application. You need a security manager if you are downloading code from the server, however you do not need to do this for this application. When you decide which methods you wish to use remotely, you will run the RMI Compiler (rmic) which will generate a file named <class name>_stub (so if your class was called Server.java, you would get a new file created called Server_stub.java). Since this stub file will be in your executable jar file, the client application will already know where it is, and it will not attempt to download the stubs dynamically.
As for the point that, if I don't use RMI, I must work out an ad-hoc protocol to transfer info: I must implement a stand-alone mode where there is no object serialisation. So I must work out an ad-hoc protocol to transfer info *anyway*, so what's the extra difficulty with sockets?
In stand alone mode, you are not using an ad-hoc protocol (or any protocol) to pass data - you are calling methods in classes and using the data it returns. But if you use sockets, then you have to work out a protocol for connecting the clients to the server, creating new threads to handle the connections, transfering the query from the client to the server, and for transferring the results from the server back to the client. With RMI, you simply write your application as though it was all being run locally. Then you just declare some methods to be remote methods, do a recompile, and let Java handle all the messy bits. OK, I left out a few steps, but not much. To make this clearer, here is example code to run locally:
Now lets make it RMI:
And on the server side, I have an interface:
And server code:
That was not very difficult! Actually I left stuff out - primarily exception handling. And this is in no way the correct code for the assignment, but you should be able to see how easy this is. Contrast this with writing raw socket code. Just connectivity would be more than this. Then you have to serialize your objects and pass them over the network and rebuild them on the other side, and you would have to work out your protocol to handle all this. Hope this cleared some things up. Regards, Andrew
More on how simple RMI should be ... rather than give you a theoretical "we dont need no dang security manager" etc., I thought I'd give you some real code so you can try it out. Save this as RmiSample.java
Compile it (java RmiSample.java) The run the RMI compiler on the Server class (rmic Server) Then in one window, run java RmiSample server And in another window run java RmiSample You should see that the code runs ... output will be sent to both windows. And we did not need to play with a security manager or a web server. The argument "server" is just a placeholder - my bad coding simply counts arguments, so it could be anything to make the server run 45 lines to write a multi user networked application which has both client and server code. Regards, Andrew
Originally posted by Perry Board: I think RMI is much simpler than sockets. You can call methods on a remote object just like it were a local object. With sockets, you'll need to do all the hard work yourself of inventing a protocol for your messages, then interpreting it at either end and doing the appropriate thing. Try the RMI tutorial on the Sun site and you'll see how easy it is. If you are set on sockets, why not just pick an arbitrary high port number to use and don't change it unless the user specifically says to use a special port. [ May 08, 2003: Message edited by: Perry Board ]
Please clarify "unless the user specifically says to use a special port". Once a server starts how could the user (or client) choose a different port ? Actually I am not sure how even the socket based server can choose the port at run time, since my application cannot set any command line arguments other than the "mode flag". So as I understand we just pick a port number > 1023 and bake it in the server code !! Then in the client we set this code as a config parameter (not baked in code). Is my understanding correct or am I way off base? thanks in advance -- Raghavan