From: Kevin McMurtrie on
In article <8336rcF703U1(a)mid.individual.net>,
Mike Amling <mamling(a)rmcis.com> wrote:

> Felce e Mirtillo wrote:
> > 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.
--
I won't see Google Groups replies because I must filter them as spam