Java Reference
In-Depth Information
How It Works
Now take a look at the way this code works.
1.
On the server's side, a ServerSocket is created that will listen for incoming connections on the
local computer (the default) on port 9000 , using TCP/IP. (UDP/IP server‐client programs, on the
other hand, are created through another class, DatagramSocket .)
2.
Next, the server performs a loop that accepts a client connection (using a second socket), reads a
message from the client, sends back an acknowledgement, and closes the output stream. If a client
sends a STOP message, the server will stop accepting new connections and will close itself down.
Note that the stream types are matching on both sides of the connection (data input and output
streams). Also note the use of writeUTF and readUTF to make sure the client and server can com-
municate by using the full Unicode spectrum (e.g., also in Mandarin).
3.
On the client's side, a normal socket is created to connect to localhost (the hostname denoting the
local computer; you can also use the special IP address 127.0.0.1 , which also refers to the local
computer). The user is then asked to enter a message, which is sent to the server. Next, as long as the
server is sending back data, the reply to the user is printed out before closing the connection.
4.
If you get a "java.net.BindException: Address already in use: JVM_Bind" exception on the
server's side, this means that a TCP/IP socket is already listening on port 9000 . Make sure you haven't
started TCPServer multiple times, or try to change the port number in TCPServer and TCPClient to
something else—perhaps there is another program on your computer listening to this port number.
5.
Take some time if you want to experiment with the program and try out some simple modifica-
tions. For instance, try changing the client and server classes to allow the client to send multiple
lines before receiving a reply from the server. To indicate when the client has finished sending its
message, you can use another terminator string (such as a blank newline, like the one used in the
HTTP protocol).
The setup of this example might not seem too difficult to understand, but this example has been kept
deliberately simple. Once more functionality is required, things start getting more complex rather
quickly. For example, you have created a simple request‐reply “protocol” here, which is much simpler
to implement than a program where both the client and the server transmit a number of messages to
each other. In addition, try launching multiple client programs at once. You'll note how the server is
able to deal with only one client at once, forcing the other one to wait to establish its connection. This
means that, if you run this program in a real‐life setting, one single client can block access to the ser-
vice by just waiting indefinitely to send its message. To overcome this problem, you need to use a mul-
tithreaded setup where multiple connections can be active at once (and dealt with separately in parallel
running threads). Finally, this program is also “blocking,” meaning that when you write something like
reply = incoming.readUTF() , the execution of the program will stop until actual data is received
(this is why you close the outgoing stream explicitly on the server's side). So‐called “asynchronous”
(non‐blocking) communication is also possible in Java, but is harder to implement correctly.
Luckily, Java comes with a number of libraries and frameworks that help to abstract away a lot of this
complexity, so that you can focus on the task at hand—accessing actual information over the networks
and the Internet.
Search WWH ::




Custom Search