Java socket....
in [Java Programming]
|
From: EJP on 21 Apr 2010 02:16 On 20/04/2010 10:38 PM, Mike Amling wrote: > 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.
From: Mike Amling on 23 Apr 2010 11:15 Arne Vajhøj wrote: > On 20-04-2010 12:42, RedGrittyBrick wrote: >> On 20/04/2010 11:39, Roedy Green wrote: >>> On Mon, 19 Apr 2010 12:10:10 +0200, Felce e Mirtillo >>> <dario.fantoni(a)gmail.com> wrote, quoted or indirectly quoted someone >>> who said : >>> >>>> count = socket.getInputStream().read(); >>>> while (count> 0&& count != 3) { >>> >>> 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? > > 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
From: Gilbert on 12 May 2010 15:38 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... > 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
From: EJP on 19 May 2010 07:23
On 13/05/2010 5:38 AM, Gilbert wrote: > 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. |