Solved

Multithreaded TCP/IP client

Posted on 2001-08-22
5
574 Views
Last Modified: 2009-12-16
Is there any source code for a multithreaded TCP/IP client?  I need to be able to send and receive data, without "hanging" on sends and receives.
0
Comment
Question by:joegood
  • 3
5 Comments
 
LVL 19

Expert Comment

by:Jim Cakalic
ID: 6413944
The Java Tutorial provides an annotated example with source of a simple multi-threading socket server that you might want to look at for reference.
   http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

And Allen Holub wrote a JavaWorld article on the use of thread pools in socket server applications.  It is a bit more advanced than the simple example from Java Tutorial. You might find it interesting:
    http://www.javaworld.com/javaworld/jw-05-1999/jw-05-toolbox-3.html

And here is an example of a simple multi-threading Web Server at the Java Developer Connection.
    http://developer.java.sun.com/developer/technicalArticles/Networking/Webserver/

FYI, JDK 1.4 will include support for multiplexed non-blocking I/O using a facility called "channels". This could significantly reduce the need for large numbers of threads in server applications. The 1.4 Beta has been released and can be downloaded from the Java Developer Connection:
   http://java.sun.com/j2se/

Best regards,
Jim Cakalic
0
 
LVL 3

Expert Comment

by:exorcist
ID: 6414137
These are some good explanations on how to write a SERVER but not a CLIENT. The first link is part of a tutorial that is definitely worth reading and also includes the client side. In addition you could just look for Tutorials with a search engine looking after words like +"java networking" +tutorial

There should be several out there.
0
 
LVL 19

Expert Comment

by:Jim Cakalic
ID: 6414538
Ah, yes, missed the word "client". One simple method for avoiding infinite read blocks Socket I/O is to use the Socket.setSoTimeout method. For your reference, the javadoc states:

"Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.io.InterruptedIOException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout."

With SO_TIMEOUT set, you would enter the blocking read and have a catch block for InterruptedIOException which would only occur if data was not received before the expiration of the timout period. You will also need to catch SocketException which can be thrown by the setSoTimeout method.

An article related to timed socket operations appeared on JavaWorld some time back. It discusses use of SO_TIMEOUT further and presents a TimedSocket class to simplify timeout handling. (JavaWorld is in the midst of making major site changes so things are a little slow and ugly right now.)
    http://www.javaworld.com/jw-09-1999/jw-09-timeout.html

Best regards,
Jim Cakalic
0
 
LVL 92

Accepted Solution

by:
objects earned 200 total points
ID: 6415844
You can call available() before doing your read to determine if any data is available to read (and how much).
This way you can totally avoid any blocking reads.
0
 
LVL 19

Expert Comment

by:Jim Cakalic
ID: 6418191
Just be careful when wrapping the Socket InputStream with a BufferedInputStream that you always use the BufferedInputStream's available method because it reads and buffers data from the Socket's InputStream. If you instead call the Socket InputStream available method, it may report nothing to read when the wrapping BufferedInputStream has buffered data available.

Of course, BufferedReader doesn't have an available method. Instead you would use its ready method. In this case, be aware of a defect in JDK 1.3 that will cause unexpected blocking behavior if you are using the readLine method to read newline sequence terminated String data from the Socket. The BufferedReader doesn't fully consume the newline sequence if it \r\n. Instead, it leaves the \n in the buffer. The next call to ready returns true even when the only character in the buffer is the \n character. A subsequent call to readLine will block -- perhaps forever depending on your protocol. This defect was introduced in 1.3 so 1.2.2 is safe. The JDC Bug Database indicates that it has been fixed in JDK 1.4.

Jim
0

Featured Post

Use Case: Protecting a Hybrid Cloud Infrastructure

Microsoft Azure is rapidly becoming the norm in dynamic IT environments. This document describes the challenges that organizations face when protecting data in a hybrid cloud IT environment and presents a use case to demonstrate how Acronis Backup protects all data.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Application launch issue with Apache Tomcat 5 45
Cipher Configuration on Apache HTTPD 4 62
servlet example 17 32
Which non-HTML GUI front end to use with Java? 3 22
An old method to applying the Singleton pattern in your Java code is to check if a static instance, defined in the same class that needs to be instantiated once and only once, is null and then create a new instance; otherwise, the pre-existing insta…
Java functions are among the best things for programmers to work with as Java sites can be very easy to read and prepare. Java especially simplifies many processes in the coding industry as it helps integrate many forms of technology and different d…
The viewer will learn how to implement Singleton Design Pattern in Java.
This tutorial explains how to use the VisualVM tool for the Java platform application. This video goes into detail on the Threads, Sampler, and Profiler tabs.

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question