client socket to read individual messages

[kishan.bisht]

This is cross posting to reach wider programmers as my problem is
urgent

http://forums.sun.com/thread.jspa?threadID=5363599&tstart=0

Basically I am looking for two way communication in single client
socket connection where I am able to understand individual messages
sent by server socket.

Thanks

 

[John B. Matthews]

This is cross posting to reach wider programmers as my problem is
urgent

http://forums.sun.com/thread.jspa?threadID=5363599&tstart=0

Basically I am looking for two way communication in single client
socket connection where I am able to understand individual messages
sent by server socket.

In the thread you cited, the suggestion of using a length to frame the
individual messages seems appealing.

You also mentioned "time constraints"; can you elaborate?

 

[Arne Vajhøj]

In the thread you cited, the suggestion of using a length to frame the
individual messages seems appealing.

Very appealing. That is how it is done.

Arne

 

[EJP]

I assume he meant that he doesn't have time to explore other options.

He doesn't have time to get it wrong either ...

 

[Arved Sandstrom]

Very appealing. That is how it is done.

Arne

It's a common _and_ common-sense technique. What it boils down to is, you're
defining a protocol, and message-length (or length of part of the message)
is one way of describing a message. HTTP 1.1 uses both headers and
length...this protocol is a source of ideas for anyone looking to write
their own, which is essentially what the OP needs.

I recently had to devise a simple protocol of my own for a socket situation.
Readers here will know about Runtime.exec behaviour on Solaris and Linux,
and one classic solution for that problem is to write a little server
running in a stripped-down JVM to handle the Runtime.exec's. Of course, you
now need to communicate with this server from your main app, hence a
protocol. In my case the protocol was: send two lines (newline terminated)
to the socket server...period. The main app expected one line back, after
which the connection was closed. Very simple.

We have another situation where we'd like to use this "miniserver", but this
time the message will have a payload. In which case we'll need to
differentiate between message types and also describe payload length...both
easily handled by headers just like in HTTP. In effect my existing message
type just consists of 2 header lines.

AHS

 

[kishan.bisht]

It's a common _and_ common-sense technique. What it boils down to is, you're
defining a protocol, and message-length (or length of part of the message)
is one way of describing a message. HTTP 1.1 uses both headers and
length...this protocol is a source of ideas for anyone looking to write
their own, which is essentially what the OP needs.

I recently had to devise a simple protocol of my own for a socket situation.
Readers here will know about Runtime.exec behaviour on Solaris and Linux,
and one classic solution for that problem is to write a little server
running in a stripped-down JVM to handle the Runtime.exec's. Of course, you
now need to communicate with this server from your main app, hence a
protocol. In my case the protocol was: send two lines (newline terminated)
to the socket server...period. The main app expected one line back, after
which the connection was closed. Very simple.

We have another situation where we'd like to use this "miniserver", but this
time the message will have a payload. In which case we'll need to
differentiate between message types and also describe payload length...both
easily handled by headers just like in HTTP. In effect my existing message
type just consists of 2 header lines.

AHS

Thanks all.
As you guessed cannot be done without using the message length
protocol which I used successfully.
The only problem is when I relay back to the originating server all
these messages the originating server always receives messages after
the timeout irrespective how big/small is the timeout. I am suspecting
my proxy-return type socket output stream is flawed or something else
in protocol.

Lets see