/**
* Aji, try: ServerSocketChannel.java
*
* This seems to be recurrent, I believe:
*
* Windows, I/O is not interruptable. I/O and Streams 15 Friday, April 20, 2007 Nicholas Jordan
* *
* A selectable channel for stream-oriented listening sockets is necessary
* for a reasonably efficient solution, you are using a socket from java.net
* which may be single threaded.
*
* Server-socket channels are not a complete abstraction of listening
* network sockets. Binding and the manipulation of socket options must be
* done through an associated {@link java.net.ServerSocket} object obtained by
* invoking the {@link #socket() socket} method. It is not possible to create
* a channel for an arbitrary, pre-existing server socket, nor is it possible
* to specify the {@link java.net.SocketImpl} object to be used by a server
* socket associated with a server-socket channel.
*
* A server-socket channel is created by invoking the {@link #open() open}
* method of this class. A newly-created server-socket channel is open but not
* yet bound. An attempt to invoke the {@link #accept() accept} method of an
* unbound server-socket channel will cause a {@link NotYetBoundException} to
* be thrown. A server-socket channel can be bound by invoking one of the
* {@link java.net.ServerSocket#bind(java.net.SocketAddress,int) bind} methods
* of an associated server socket.
*
* Server-socket channels are safe for use by multiple concurrent threads.
* ServerSocket.java may not be, in which idea would explain your question.
*/
Another thing I see is doing calcs in a paint method:
d = getSize();
xmax = d.width - 1;
ymax = d.height - 1;
xcntr = xmax / 2;
ycntr = ymax / 2;
g.setColor(Color.BLACK);
drawLayout(g);
g.setColor(Color.RED);
drawPlots(g);
Don't call repaint from run, it does not make good design sense to put it there. What you do is after doing calcs, call a method that informs the OS that you would like to call paint at the next redraw. One would not call paint in this program.
Also, be though it not Saloon coding convention, I would code your Drop::run like this.
Also, you have your //Toggle status. reversed
//Wait until message has been retrieved. is in the wrong place as I see the problem description.
The wait loop is not coded properly by my estimation.
Much of your code concerns its authorship as the writer of the
applet, and as Stan James states:
Did you write the server side, too ? How the server runs has a lot to do with how the client is coded, is this a problem in a student lab where you have the ablilty to write according to what an instructor tells you ?
If not, is it on your own machine ? You can write a server that runs on your own maching, and by writing both sides of the transaction .... gain a much better foothold on the answer to your question.
In general, you would code a server thus:
Looking in the spec's it says:
/**
* Sets the server socket implementation factory for the
* application. The factory can be specified only once.
* <p>
* When an application creates a new server socket, the socket
* implementation factory's <code>createSocketImpl</code> method is
* called to create the actual socket implementation.
* <p>
* Passing <code>null</code> to the method is a no-op unless the factory
* was already set.
*/
It is very convouted to dig the logic out of OO coding practices. You just have a knotty problem, you must be willing to stay with it for us to help you.
Yes:
... guarantee that server is ready to receive by the time Socket() is sending. And:
...... believe there should be some coding techniques for this matter. What I do is just keep reading and writing code, much of it seems to come to understanding before long time running.
[ September 21, 2007: Message edited by: Nicholas Jordan ]
[ September 22, 2007: Message edited by: Nicholas Jordan ]