From: Kevin McMurtrie on 20 Apr 2010 00:18 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
|
Pages: 1 Prev: Problem while implementing ehCache Framework Next: How to set version to jar? |