Solved

Multithreaded TCP/IP client

Posted on 2001-08-22
5
572 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

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Java contains several comparison operators (e.g., <, <=, >, >=, ==, !=) that allow you to compare primitive values. However, these operators cannot be used to compare the contents of objects. Interface Comparable is used to allow objects of a cl…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
Viewers learn about the scanner class in this video and are introduced to receiving user input for their programs. Additionally, objects, conditional statements, and loops are used to help reinforce the concepts. Introduce Scanner class: Importing…
The viewer will learn how to implement Singleton Design Pattern in Java.

706 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

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now