Re: Non-blocking and semi-blocking Sockets class.
In article <CdErh.16731$Ch1.12840@trndny04>, "Karl Uppiano"
<karl.uppiano@verizon.net> wrote:
"nukleus" <nukleus@invalid.addr> wrote in message
news:eomuht$3m3$4@sage.ukr.net...
I am working on a network related application.
There is an issues with sockets blocking and how to handle it.
There are several approaches:
3. Blocking socket running as a separate thread.
This seems to be the best overall approach, as we can allow
the socket thread to block, but we are not block on the main
thread level and all our gui stuff operations as advertised.
But there are issues with this. Since you are running a separate
thread, how do you tell it what command we issue to the server
and how does the main thread knows when operation is completed
successfuly. Anotherwords, how do you exchange the information
and various error conditions between the main object and the socket?
Does anyone have any feedback on this all?
Thanks in advance.
For clients and smaller server applications, Solution 3 seems like the best
option to me. Your concerns about communicating between threads can be
solved with standard threading design patterns. Java 1.5 introduced three
entire packages devoted to thread synchronization (java.util.concurrent,
java.util.concurrent.atomic and java.util.concurrent.locks). I think you
need to look into that part of the problem.
Well... Unfortunately, i am using jdk 1.3.
So...
Package java.nio (possibly option 4) is good for server networking
applications that need to scale massively, but NIO has a pretty steep
learning curve.
State machines... I have written lots of them. They usually consist of a
state variable that might hold a reference to an interface or abstract base
class that implements the state.
interface state {
/**
* State implementations execute their state,
* and set a state variable to the "next" state.
*/
public void execute();
}
class stateMachine {
stateVariable = new state0();
while(true) {
stateVariable.execute();
}
}
Obviously, this pseudo code glosses over the details. I would probably make
the state implementations inner classes of the state machine, so they would
have access to stateVariable to set it. I might even make the state
implementations themselves stateless, and static final, so setting the state
would be a simple assignment of "constants". Maybe enums could represent the
state. I haven't had to do a state machine since Java 1.5 introduced enums,
but it sounds promising.
Thanks.