Non-blocking and semi-blocking Sockets class.

N

nukleus

I am working on a network related application.
There is an issues with sockets blocking and how to handle it.
There are several approaches:

1. Use blocking sockets and set timeout.
In this case, if connection is lost or socket object is not created
yet as we are in the middle of connect operation, the process
effectively hangs and user has to wait for timeout expiration.
Not a very desirable approach.

2. Use byte reads and buffered input stream and check
if data is available. In case of text, if it is, then read it
until you get a line separator character, and then return
a text line to a caller of getLine().

If eof condition happens, returned by -1 on a read,
that could mean the server closed a connection for whatever reason.
In this case, simply return. Non blocking operation.

If there is nothing in the buffer, but you are waiting for a server
standard response or data, you loop untill such data arrives.
This is blocking operation and has all sorts of nasty side effects.
The loop uses a separate timer from the socket timeout timer.
When that timer expires, the getLine() returns with error or
throws a TimeOut exception.

But it could be resolved usint a separate thread for a blocking socket.

One of the alternatives here is to use a byte read loop with that
could be interrupted, say, if user realizes there is error, and hits
Cancel button. In this case, the event handler sets the event,
that is tested in a read loop, and if the flag is set, the loop
terminates.
This is interruptible blocking operation, which should effectively
behave like a non-blocking operation for practical purposes.

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?

From windows C++ standpoint, you can go asynchronous using
overlapped structures for one thing.

Question: what is the best approach with java and what are the
exact steps to design the separate socket thread?
Do we use Events?
What happens to Exceptions running in a separate thread that
need to be communicated to a different thread of different frame object?

Since we create a separate thread for a socket that has its own
run() loop and we could be performing either send or receive
network operation, how do we exchange data between socket
thread and a parent class?

4. Fully asynchronous design.
This design, by definition, is non-blocking.
The overall architecture may be implemented with a state machine
approach. In this case, there is never any blocking on a socket
object. But how do you do it in Java?
It seems events are the way to go, but how do you set up your
architecture to do it?

Related question:
Anyone can suggest a good state machine design in Java?
I used my own design in C++ that had a vector of state class
objects and a state machine iterating code. Each state object
had a paramter telling it which is the next state to proceed to
in case of successful result, which state to proceed to in case
of error result, and which alternative states to proceed to in
case of minor error conditions, such as incorrect user command
issued to the server in our situation, or incorrect value of data
passed to server.

This design is flexible in that the state machine could even be
substituted for another state machine, need be. For example,
if you are trying to send email, and you made a mistake in your
configuration that tells the server that you are connecting to
NNTP server, than the server log-in response code would be
different. In this case, you could switch the state machine on
the fly and perform the NNTP related operation. This is just
and abstract example. You wouln't probably want to do that
in real life. :--}

Does anyone have any feedback on this all?

Thanks in advance.
 
K

Knute Johnson

nukleus said:
I am working on a network related application.
There is an issues with sockets blocking and how to handle it.
There are several approaches:

1. Use blocking sockets and set timeout.
In this case, if connection is lost or socket object is not created
yet as we are in the middle of connect operation, the process
effectively hangs and user has to wait for timeout expiration.
Not a very desirable approach.

2. Use byte reads and buffered input stream and check
if data is available. In case of text, if it is, then read it
until you get a line separator character, and then return
a text line to a caller of getLine().

If eof condition happens, returned by -1 on a read,
that could mean the server closed a connection for whatever reason.
In this case, simply return. Non blocking operation.

If there is nothing in the buffer, but you are waiting for a server
standard response or data, you loop untill such data arrives.
This is blocking operation and has all sorts of nasty side effects.
The loop uses a separate timer from the socket timeout timer.
When that timer expires, the getLine() returns with error or
throws a TimeOut exception.

But it could be resolved usint a separate thread for a blocking socket.

One of the alternatives here is to use a byte read loop with that
could be interrupted, say, if user realizes there is error, and hits
Cancel button. In this case, the event handler sets the event,
that is tested in a read loop, and if the flag is set, the loop
terminates.
This is interruptible blocking operation, which should effectively
behave like a non-blocking operation for practical purposes.

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?

From windows C++ standpoint, you can go asynchronous using
overlapped structures for one thing.

Question: what is the best approach with java and what are the
exact steps to design the separate socket thread?
Do we use Events?
What happens to Exceptions running in a separate thread that
need to be communicated to a different thread of different frame object?

Since we create a separate thread for a socket that has its own
run() loop and we could be performing either send or receive
network operation, how do we exchange data between socket
thread and a parent class?

4. Fully asynchronous design.
This design, by definition, is non-blocking.
The overall architecture may be implemented with a state machine
approach. In this case, there is never any blocking on a socket
object. But how do you do it in Java?
It seems events are the way to go, but how do you set up your
architecture to do it?

Related question:
Anyone can suggest a good state machine design in Java?
I used my own design in C++ that had a vector of state class
objects and a state machine iterating code. Each state object
had a paramter telling it which is the next state to proceed to
in case of successful result, which state to proceed to in case
of error result, and which alternative states to proceed to in
case of minor error conditions, such as incorrect user command
issued to the server in our situation, or incorrect value of data
passed to server.

This design is flexible in that the state machine could even be
substituted for another state machine, need be. For example,
if you are trying to send email, and you made a mistake in your
configuration that tells the server that you are connecting to
NNTP server, than the server log-in response code would be
different. In this case, you could switch the state machine on
the fly and perform the NNTP related operation. This is just
and abstract example. You wouln't probably want to do that
in real life. :--}

Does anyone have any feedback on this all?

Thanks in advance.
Click to expand...

Use 3. I assume your data is some kind of message? Just have a read
thread that takes in the data and calls methods appropriate to the
message. The output can be handled from the GUI. The simpler you make
it the more reliable and maintainable it will be.

Just my 2 cents.
 
K

Karl Uppiano

nukleus said:
I am working on a network related application.
There is an issues with sockets blocking and how to handle it.
There are several approaches:

1. Use blocking sockets and set timeout.
In this case, if connection is lost or socket object is not created
yet as we are in the middle of connect operation, the process
effectively hangs and user has to wait for timeout expiration.
Not a very desirable approach.

2. Use byte reads and buffered input stream and check
if data is available. In case of text, if it is, then read it
until you get a line separator character, and then return
a text line to a caller of getLine().

If eof condition happens, returned by -1 on a read,
that could mean the server closed a connection for whatever reason.
In this case, simply return. Non blocking operation.

If there is nothing in the buffer, but you are waiting for a server
standard response or data, you loop untill such data arrives.
This is blocking operation and has all sorts of nasty side effects.
The loop uses a separate timer from the socket timeout timer.
When that timer expires, the getLine() returns with error or
throws a TimeOut exception.

But it could be resolved usint a separate thread for a blocking socket.

One of the alternatives here is to use a byte read loop with that
could be interrupted, say, if user realizes there is error, and hits
Cancel button. In this case, the event handler sets the event,
that is tested in a read loop, and if the flag is set, the loop
terminates.
This is interruptible blocking operation, which should effectively
behave like a non-blocking operation for practical purposes.

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?

From windows C++ standpoint, you can go asynchronous using
overlapped structures for one thing.

Question: what is the best approach with java and what are the
exact steps to design the separate socket thread?
Do we use Events?
What happens to Exceptions running in a separate thread that
need to be communicated to a different thread of different frame
object?

Since we create a separate thread for a socket that has its own
run() loop and we could be performing either send or receive
network operation, how do we exchange data between socket
thread and a parent class?

4. Fully asynchronous design.
This design, by definition, is non-blocking.
The overall architecture may be implemented with a state machine
approach. In this case, there is never any blocking on a socket
object. But how do you do it in Java?
It seems events are the way to go, but how do you set up your
architecture to do it?

Related question:
Anyone can suggest a good state machine design in Java?
I used my own design in C++ that had a vector of state class
objects and a state machine iterating code. Each state object
had a paramter telling it which is the next state to proceed to
in case of successful result, which state to proceed to in case
of error result, and which alternative states to proceed to in
case of minor error conditions, such as incorrect user command
issued to the server in our situation, or incorrect value of data
passed to server.

This design is flexible in that the state machine could even be
substituted for another state machine, need be. For example,
if you are trying to send email, and you made a mistake in your
configuration that tells the server that you are connecting to
NNTP server, than the server log-in response code would be
different. In this case, you could switch the state machine on
the fly and perform the NNTP related operation. This is just
and abstract example. You wouln't probably want to do that
in real life. :--}

Does anyone have any feedback on this all?

Thanks in advance.
Click to expand...

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.

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.
 
A

Andrew Thompson

Sorry. Is that the AWT application you were
referring to, ealier? (another thread, different issue
re. layouts).

Because I meant to ask at the time, why the
application was AWT based, which suggests
to me that it is very old. Swing was a bit shaky
in 1.2, but by Java 1.3, it was quite usable.

Do you need to support older VMs?
If so, what minimum version?

Which then brings me (after a big snip) to..
...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.
Click to expand...

...If you actually need to support the application at
a specific Java version (pre. 1.5), it might be a good
idea to mention that on any thread related to the
application, as people would have to 'think back',
even to remember what could be supported in 1.4!

Andrew T.
 
N

nukleus

Knute Johnson said:
Use 3. I assume your data is some kind of message? Just have a read
thread that takes in the data and calls methods appropriate to the
message. The output can be handled from the GUI. The simpler you make
it the more reliable and maintainable it will be.
Click to expand...

Thanks. That is i was thinking of. I'll try.
 
N

nukleus

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.
Click to expand...

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.
Click to expand...
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();
}
}
Click to expand...
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.
Click to expand...

Thanks.
 
N

nukleus

"Andrew said:
Sorry. Is that the AWT application you were
referring to, ealier? (another thread, different issue
re. layouts).
Yep.

Because I meant to ask at the time, why the
application was AWT based, which suggests
to me that it is very old. Swing was a bit shaky
in 1.2, but by Java 1.3, it was quite usable.
Click to expand...

The problem is, i am using ms vj2003 which does not have
javax stuff and i AM using jdk 1.3. It would be great if i could
somehow turn on the javax libraries as it has some nice features,
but i just don't know if it is possible. I have to live with what i got.
Do you need to support older VMs?
If so, what minimum version?
Click to expand...

Yep. I think going back to jdk 1.3.
Which then brings me (after a big snip) to..
Click to expand...
...If you actually need to support the application at
a specific Java version (pre. 1.5), it might be a good
idea to mention that on any thread related to the
application, as people would have to 'think back',
even to remember what could be supported in 1.4!
Click to expand...

I see... Thanks.
 
N

nukleus

"Chris Uppal" said:
Thanx.

BTW, why are you limited to 1.3 ? I'm only curious, but I can't think of any
plausible reason myself.
Click to expand...

Because that is all i have at the moment.
Secondly, as i understand, 1.3 is stable enough.
I read some articles about all sorts of issues with 1.4.
My development environment does not support anything beyond 1.3.
:--{

Such is life...

Do you have any idea, by any chance if it is possible to turn on
the javax library in ms vj++ 2003?
 
C

Chris Uppal

nukleus wrote:

[me:]
Because that is all i have at the moment.
Click to expand...

Seems an easy enough problem to fix ;-)

Secondly, as i understand, 1.3 is stable enough.
Click to expand...

My vague memory is of 1.3 not being impressively stable. It's a long time ago,
though, so I could easily be mis-remembering. But that's the main point -- 1.3
is so old that it's obsolete.

My development environment does not support anything beyond 1.3.
:--{
Click to expand...

I suggest changing your development environment -- at least for Java work.

Do you have any idea, by any chance if it is possible to turn on
the javax library in ms vj++ 2003?
Click to expand...

Not the faintest, I'm afraid. I dislike MS's dev tools in the first place
(even though I'm a Windows user) even for C++ work; and wouldn't even consider
using them for Java, so I have no experience with vj++ at all.

-- chris
 
L

Lew

nukleus said:
The problem is, i am using ms vj2003 which does not have
javax stuff and i AM using jdk 1.3. It would be great if i could
somehow turn on the javax libraries as it has some nice features,
but i just don't know if it is possible. I have to live with what i got.
Click to expand...

According to Sun, <http://java.sun.com/javase/downloads/previous.jsp>:

"J2SE 1.3.1 has begun the Sun End of Life (EOL) process. The EOL transition
period is from Oct 25, 2004 until the General Availability (GA) of the next
Java version, Java SE 6."

Java 6 has been out for a few weeks, so guess what? The two-plus year "EOL
transition" is officially over, and Java 1.3 is obsolete. Unsupported. Dead.

For over two years Java 1.3 has been moribund. How long do people need to move on?

- Lew
 
L

Lew

Chris said:
Not the faintest, I'm afraid. I dislike MS's dev tools in the first place
(even though I'm a Windows user) even for C++ work; and wouldn't even consider
using them for Java, so I have no experience with vj++ at all.
Click to expand...

Isn't that the MS version of "Java" that lost them that lawsuit from Sun for
trademark violation, since it was not a compatible language and therefore not
really Java?

- Lew
 
N

nukleus

Lew said:
Isn't that the MS version of "Java" that lost them that lawsuit from Sun for
trademark violation, since it was not a compatible language and therefore not
really Java?
Click to expand...

I think it is becasue they did have javax in vj++ 6, but in 2003 version
it was all gone.
 
C

Chris Uppal

Lew wrote:

[me:]
Isn't that the MS version of "Java" that lost them that lawsuit from Sun
for trademark violation, since it was not a compatible language and
therefore not really Java?
Click to expand...

If I remember correctly that particular legal fuss (justified, IMO) was at the
time of MS Visual Studio 6 and the incompatible implementation of Java that MS
were pushing around that time. The corresponding element of Visual Studio was
"Visual J++ 6" (which didn't ship as a standard component of the IDE --
presumably because of the "fuss").

My /guess/ is that the OP, when he said "vj++" was really meaning Visual J#,
since VJ++ is not part of VS 2003, but Visual J# is. That targets the
Java-like Java-like language J# -- which has not (as far as I know) been the
subject of any lawsuits.

-- chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

non-blocking sockets 1
non blocking sockets and alternatives 1
Non-blocking sockets 9
Retrieving Sender Information From A Non-blocking DatagramChannel 2
Question about non-blocking NIO and Selection Keys 12
Non-blocking sockets? 1
Non Blocking Sockets - Puzzling issue 1
Blocking queue race condition? 10

Members online

Total: 313 (members: 1, guests: 312)
Robots: 107

Forum statistics

Threads
473,968
Messages
2,570,149
Members
46,695
Latest member
StanleyDri

Latest Threads

Top