Solved

Multithreaded TCP/IP client

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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

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

Introduction Java can be integrated with native programs using an interface called JNI(Java Native Interface). Native programs are programs which can directly run on the processor. JNI is simply a naming and calling convention so that the JVM (Java…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
This video teaches viewers about errors in exception handling.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

914 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

17 Experts available now in Live!

Get 1:1 Help Now