Java socket....

[Felce e Mirtillo]

Hi all,

I'm writing an application to interface a device ( industrial balance )
to a PC via TCP/IP... well the device acts as Server and my application
is a listening client.

Th client receive a single string
<stx>dd/mm/yyyy;hh:mm;0000000000;A;0000000000<etx>
that I read with... a method like this:

....
byte[] buffer = new byte[100];
int count = 0, offset = 0;

count = socket.getInputStream().read();
while (count > 0 && count != 3) {
buffer[offset++] = count;
count = socket.getInputStream().read();
}
String line = new String(buffer, 1, offset);
String[] dati = new String[5]
offset = 0;
for(StringTokenizer t = new StringTokenizer(line, ";");
t.hasMoreTokens() dati[offset++] = t.nextToken();
....

well the method is in a loop where I'd would trap
some events. The most important is... if someone
swich off the device and then switch off... the
previous method remain 'blocked' waiting the next
byte ...
I've tryed several Socket methods.. but no one of
them is usefull in order to intercept the death
of tcp/ip connection...

What can I do... ???
Any Idea ???
Thanks in advance...


Dario
(I apologize for my poor english.. I hope it is better than your average
italian )

 

[Mike Amling]

Hi all,

I'm writing an application to interface a device ( industrial balance )
to a PC via TCP/IP... well the device acts as Server and my application
is a listening client.

Th client receive a single string
<stx>dd/mm/yyyy;hh:mm;0000000000;A;0000000000<etx>
that I read with... a method like this:

...
byte[] buffer = new byte[100];
int count = 0, offset = 0;

count = socket.getInputStream().read();
while (count > 0 && count != 3) {
buffer[offset++] = count;
count = socket.getInputStream().read();
}
String line = new String(buffer, 1, offset);
String[] dati = new String[5]
offset = 0;
for(StringTokenizer t = new StringTokenizer(line, ";");
t.hasMoreTokens() dati[offset++] = t.nextToken();
...

well the method is in a loop where I'd would trap
some events. The most important is... if someone
swich off the device and then switch off... the
previous method remain 'blocked' waiting the next
byte ...
I've tryed several Socket methods.. but no one of
them is usefull in order to intercept the death
of tcp/ip connection...

What can I do... ???
Any Idea ???
Thanks in advance...

You need some kind of ping to make sure the device. When the device
is turned off, all the control blocks for the TCP connection on the
machine running Java remain valid. If no packets are being exchanged,
there's no indication that anything is wrong.
Is there a harmless message you could send to the device that would
have no side effects? If so, send it every once in a while from a second
Thread, and after the device is off, you should get an I/O error on the
send, which will probably cause your blocked read to get either
end-of-file or an I/O error.

There's also a Socket.setKeepAlive(true), but I don't know exactly
what it's defined to do.

--Mike Amling

 

[Mike Amling]

You need some kind of ping to make sure the device.

...to make sure the device is still running.

 

[Arne Vajhøj]

Hi all,

I'm writing an application to interface a device ( industrial balance )
to a PC via TCP/IP... well the device acts as Server and my application
is a listening client.

Th client receive a single string
<stx>dd/mm/yyyy;hh:mm;0000000000;A;0000000000<etx>
that I read with... a method like this:

...
byte[] buffer = new byte[100];
int count = 0, offset = 0;

count = socket.getInputStream().read();
while (count > 0 && count != 3) {
buffer[offset++] = count;
count = socket.getInputStream().read();
}
String line = new String(buffer, 1, offset);
String[] dati = new String[5]
offset = 0;
for(StringTokenizer t = new StringTokenizer(line, ";");
t.hasMoreTokens() dati[offset++] = t.nextToken();
...

well the method is in a loop where I'd would trap
some events. The most important is... if someone
swich off the device and then switch off... the
previous method remain 'blocked' waiting the next
byte ...
I've tryed several Socket methods.. but no one of
them is usefull in order to intercept the death
of tcp/ip connection...

What can I do... ???

Eventually you will get an exception, but it takes time.

TCP/IP was designed to be able to handle slow unreliable network,
so it is patient.

To lower it you could try:

socket.setSoTimeout(1000);

Arne

PS: I think the code would be simpler if you wrapped the
InputStream in a BufferedReader and used String.split
instead of StringTokenizer.

 

[EJP]

You need some kind of ping to make sure the device.

No you don't, you just need a read timeout. Socket.setSoTimeout().

 

[Kevin McMurtrie]

Hi all,

I'm writing an application to interface a device ( industrial balance )
to a PC via TCP/IP... well the device acts as Server and my application
is a listening client.

Th client receive a single string
<stx>dd/mm/yyyy;hh:mm;0000000000;A;0000000000<etx>
that I read with... a method like this:

...
byte[] buffer = new byte[100];
int count = 0, offset = 0;

count = socket.getInputStream().read();
while (count > 0 && count != 3) {
buffer[offset++] = count;
count = socket.getInputStream().read();
}
String line = new String(buffer, 1, offset);
String[] dati = new String[5]
offset = 0;
for(StringTokenizer t = new StringTokenizer(line, ";");
t.hasMoreTokens() dati[offset++] = t.nextToken();
...

well the method is in a loop where I'd would trap
some events. The most important is... if someone
swich off the device and then switch off... the
previous method remain 'blocked' waiting the next
byte ...
I've tryed several Socket methods.. but no one of
them is usefull in order to intercept the death
of tcp/ip connection...

What can I do... ???
Any Idea ???
Thanks in advance...

You need some kind of ping to make sure the device. When the device
is turned off, all the control blocks for the TCP connection on the
machine running Java remain valid. If no packets are being exchanged,
there's no indication that anything is wrong.
Is there a harmless message you could send to the device that would
have no side effects? If so, send it every once in a while from a second
Thread, and after the device is off, you should get an I/O error on the
send, which will probably cause your blocked read to get either
end-of-file or an I/O error.

There's also a Socket.setKeepAlive(true), but I don't know exactly
what it's defined to do.

--Mike Amling

Keep-Alive does exactly what this code might need. It generates a very
small amount of background traffic so that the OS and all the hardware
between the two ends can differentiate between silence and a broken
connection.

The downside is that the keep-alive parameters and support vary. The
other end may refuse the option. A heartbeat multiplexed into the the
data stream by the code can be more reliable.

 

[Roedy Green]

count = socket.getInputStream().read();
while (count > 0 && count != 3) {

you are going two layers lower protocol layer than you need.

See http://mindprod.com/jgloss/http.html

 

[Mike Amling]

No you don't, you just need a read timeout. Socket.setSoTimeout().

A read timeout does not distinguish between a dead device and a
healthy device that has nothing to say.

--Mike Amling

 

[RedGrittyBrick]

you are going two layers lower protocol layer than you need.

Two? What layer of the TCP/IP protocol suite lies between TCP and HTTP?

See http://mindprod.com/jgloss/http.html

What makes you think his industrial balance speaks HTTP?


Aren't newbie onlookers more likely to be confused by this answer than
helped?

Just my ¤0.02 worth.

 

[Arne Vajhøj]

Two? What layer of the TCP/IP protocol suite lies between TCP and HTTP?


What makes you think his industrial balance speaks HTTP?

Aren't newbie onlookers more likely to be confused by this answer than
helped?

But he got posted a link to his web site, which seems to be more
important for him than to relate to the question.

Arne

 

[EJP]

A read timeout does not distinguish between a dead device and a healthy
device that has nothing to say.

Agreed, but it's an existing standalone device, and there is no evidence
here that its protocol can be amended to support a 'ping' transaction.

 

[Mike Amling]

But he got posted a link to his web site, which seems to be more
important for him than to relate to the question.

Arne

Amen.

Note: I don't think the problem is Roedy's deliberate attempt to plug
his web pages despite their inapplicability. I think Roedy wants to be
helpful but doesn't pick up on what the various OPs are really asking.

--Mike Amling

 

[Gilbert]

Hi all,

I'm writing an application to interface a device ( industrial balance )
to a PC via TCP/IP... well the device acts as Server and my application
is a listening client.

Th client receive a single string
<stx>dd/mm/yyyy;hh:mm;0000000000;A;0000000000<etx>
that I read with... a method like this:

...
byte[] buffer = new byte[100];
int count = 0, offset = 0;

count = socket.getInputStream().read();
while (count > 0 && count != 3) {
buffer[offset++] = count;
count = socket.getInputStream().read();
}
String line = new String(buffer, 1, offset);
String[] dati = new String[5]
offset = 0;
for(StringTokenizer t = new StringTokenizer(line, ";");
t.hasMoreTokens() dati[offset++] = t.nextToken();
...

well the method is in a loop where I'd would trap
some events. The most important is... if someone
swich off the device and then switch off... the
previous method remain 'blocked' waiting the next
byte ...
I've tryed several Socket methods.. but no one of
them is usefull in order to intercept the death
of tcp/ip connection...

What can I do... ???
Any Idea ???
Thanks in advance...

I'd consider using a socket handling library that should take
care of the low level stuff. I've recently implemented a
socket read/write application using Netty and I've been very
impressed with it. Netty implements an event model which
would allow you to catch disconnection events.

Regards

 

[EJP]

I'd consider using a socket handling library that should take
care of the low level stuff. I've recently implemented a
socket read/write application using Netty and I've been very
impressed with it. Netty implements an event model which
would allow you to catch disconnection events.

If you mean closed connection events, that's trivial: read() returns -1.
If you mean events where the connection is dropped, there is no such
event in TCP/IP, other than in response to a write(), so there can't be
such an event in any library, including java.net and java.nio ... And
Netty is just built over java.nio.