ServerSocket readLine() problem in a special situation

[wostaney]

Dear All,

I got a problem in a Java program which is used to integrated with
CyDesk client.

Situation:
I want to develop a little Java program which run in desktop.
This little program has to communicate with the CyDesk client
(installed in desktop also), like sending commands and receiving
messages.

CyDesk client is a client of PhoneSystem which is connected to a
CyDesk Server.
CyDesk client provides a socket connection for low-level integration,
but CyDesk client is a socket client!!!
That means my little program has to act as a local server to handle
all communications.
Little Program ======command=====> CyDesk Client
Little Program <======message===== CyDesk Client

Problem:
The little program has to send command (String) to CyDesk Client, when
I press some button in little program.
The little program has to receive message from CyDesk Client, when
CyDesk client has some message(String) to show me.
These two actions do not work in pairs, it means not one command then
one message back.
It means I can send any command in any time and receive messages
anytime if there are.

I can only handle one type of actions without blocking, otherwise it
hold in readLine() in my little program.

Is there any solution for this situation?
Thank you very much for helping me and reading this message.

 

[Mark Space]

I can only handle one type of actions without blocking, otherwise it
hold in readLine() in my little program.

NIO, set the operations to non-blocking. Note this will be rather more
complicated than using a socket with just readLine and printLine.

There should be several tutorials, read up and ask questions when you
get stuck.

BTW, _Learning Java_, my favorite beginning book, covers NIO in enough
detail to get a simple server up.

 

[wostaney]

I have a question about NIO.
What is the definition of "Non-blocking"?
The communication of server and one client will not block other
client?
or the communication within server and one client will not block for
next message?

Thank you so much!!!

 

[Mark Space]

I have a question about NIO.
What is the definition of "Non-blocking"?
The communication of server and one client will not block other
client?
or the communication within server and one client will not block for
next message?

Thank you so much!!!

Roughly, it doesn't matter what the other side does. If the client is
blocked on a readLine, the server doesn't have to be blocked. They are
completely independent.

Non-blocking in that context means the server does a readLine, and if
there's nothing to read, the call comes back right away with out
blocking the rest of the program. So if you server is non-blocking,
your client can block all it wants, but the server will still run.

 

[Arne Vajhøj]

I have a question about NIO.
What is the definition of "Non-blocking"?

You call a read/write (usually receive/send for net IO) and the
API guarantee that they will always return immediately.

It is most relevant for reads.

A blocking read will wait until it has at least 1 byte to
return.

A non-blocking read returns immediately with the bytes
it has even if it is zero bytes.

Arne

 

[Roedy Green]

It means I can send any command in any time and receive messages
anytime if there are.

That means you need at least two threads to deal with this. You might
implement this with a queue you can add messages to be later sent ,
and which a queue of incoming messages waiting your app is ready to
read them.

Read about consumers and producers and queues. See
http://mindprod.com/jgloss/queue.html

 

[Lew]

(e-mail address removed) wrote,

That means you need at least two threads to deal with this. You might
implement this with a queue you can add messages to be later sent ,
and which a queue of incoming messages waiting your app is ready to
read them.

Read about consumers and producers and queues. See
http://mindprod.com/jgloss/queue.html

There is a resource-manager pattern that might work here, too, albeit somewhat
more complicated. It may be too much for this particular challenge, but it
comes in handy for all sorts of things.

Consider two programs that communicate via messages. With only those two, you
have two threads for duplex communication, a receive and a transmit channel,
as Roedy suggests.

You can also create a third program, a strictly server-mode, listen-only
"resource manager", call it M, that acts as a message broker (yes, like ORBs).
Both A and B operate in strict send mode with M. One channel is the "OUT"
box - it posts messages either synchronously or asynchronously to M for
further distribution to other participants. The other channel is the "IN" box
- it posts a synchronous request for incoming messages to M. M replies if and
only if it has something for the requestor, say A for now. A gets the
message, passes it through some processing logic possibly in another thread,
then immediately sends for another. Both the "IN" and "OUT" threads strictly
send to M, i.e., they are in client mode only.

M sits in a tight loop listening for messages or requests for messages from
its clients, and immediately forwarding the posted messages to agents or other
recipients for action.

The architecture is fan-in, fan-out. Messages and requests for messages fan
in to M and out to other participants. Participants can be segmented into
groups that have specialized purposes. A simple example is a dual population
of participants; on one side of M reside all the cconsumers, on the other side
all the provider agents. It's like a taxicab company, where all the riders
call in to Dispatch to ask for a taxi, and all the drivers call in to Dispatch
to announce their readiness for the next fare.

This is easily scalable to group communications (C, D and on can join in), and
to clustered M instances.

 

[Lew]

M sits in a tight loop listening for messages or requests for messages
from its clients, and immediately forwarding the posted messages to
agents or other recipients for action.

"What if the destination isn't ready yet?" you ask? Excellent question.

M will need some storage to hold messages until their destinations finally
request them.

Likewise, if A calls for messages and there aren't any, M will put A on hold
until there are, then go back to looping for incoming dispatch orders.

M's loop is very fast, but it needs capacity to handle latency between its
clients. This is where Roedy's suggestion to use queues can be useful, also
stacks and deques. Java 6 has a panoply of such interfaces and their
implementations, e.g.,
<http://java.sun.com/javase/6/docs/api/java/util/Stack.html>
<http://java.sun.com/javase/6/docs/api/java/util/Deque.html>

I admit, it weirds me out that Stack inherits from Vector. Then again, it
does date from 1.0. Then again again, in Stack's Javadocs Sun advises

A more complete and consistent set of LIFO stack operations is provided by
the Deque interface and its implementations, which should be used in preference to this class.

It looks like Deque is Stack's ArrayList.

If you need concurrency, omigosh, there's a ton of that over in
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-frame.html>

Just read the class names down the list out loud: "AbstractExecutorService,,
ArrayBlockingQueue, ConcurrentHashMap, ConcurrentLinkedQueue, ...,
LinkedBlockingDeque, LinkedBlockingQueue, PriorityBlockingQueue, ...,
SynchronousQueue, ..."

Sheer poetry.