Multithreaded TCP/IP client

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.
joegoodAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
objectsConnect With a Mentor Commented:
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
 
Jim CakalicSenior Developer/ArchitectCommented:
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
 
exorcistCommented:
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
 
Jim CakalicSenior Developer/ArchitectCommented:
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
 
Jim CakalicSenior Developer/ArchitectCommented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.