Datagram socket problem - comp.lang.java.programmer

Got a bug somewhere... Is this bit of code going to cause problems ie the bit running in the loop? I find that the code never exits ds.receive(incoming) try { DatagramSocket ds = new DatagramSocket(Constants.LOCAL_PORT); DatagramPacket incoming = new DatagramPacket(receiveBuffer, receiveBuffer.length); incoming.setLength(60000); while(true) //Run this as an endless loop { ds.receive(incoming); packetStr = new String(receiveBuffer, 0, incoming.getLength(), "UTF-8"); if (packetStr != null) BlinkAPI.update(packetStr); } } catch (IOException e1) {} -- Dirk

On 3/27/11 1:37 PM, Dirk Bruere at NeoPax wrote: > Got a bug somewhere... Probably. What makes you so sure it's in the tiny bit of code you did post? > Is this bit of code going to cause problems ie the bit running in the > loop? I find that the code never exits ds.receive(incoming) Who's sending data? The method won't return until a datagram has actually been sent to the port on the network adapter to which the socket was bound. I don't see why you're seeing the DatagramPacket length, or if you see a need to set the length, why you don't just pass that length in to the constructor. But I don't think that would cause the failure you're seeing. You have a bug elsewhere. Pete

On Sun, 27 Mar 2011 14:19:52 -0700, Peter Duniho wrote: > On 3/27/11 2:12 PM, Peter Duniho wrote: >> [...] >> I don't see why you're seeing the DatagramPacket length [...] > > Er, "setting", not "seeing". Sorry if that was confusing. Maybe I'm stupid, but I don't see any way out of the inner 'while(true)' loop. If you're relying in an Exception to escape, at least document that in a comment. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |

On 3/27/11 3:41 PM, Martin Gregorie wrote: > On Sun, 27 Mar 2011 14:19:52 -0700, Peter Duniho wrote: > >> On 3/27/11 2:12 PM, Peter Duniho wrote: >>> [...] >>> I don't see why you're seeing the DatagramPacket length [...] >> >> Er, "setting", not "seeing". Sorry if that was confusing. > > Maybe I'm stupid, but I don't see any way out of the inner 'while(true)' > loop. If you're relying in an Exception to escape, at least document that > in a comment. I don't think you're stupid. Actually, I'm pretty certain you're not. :) Short of shutting down the network adapter, I don't see any way in that code to force an exception (e.g. closing the socket). Presumably there's code elsewhere to do the ugly "abort thread" thing. Or maybe it's a daemon thread and the OP is planning to just let it run indefinitely. Not my preferred means of managing i/o threads (well, okay…actually a daemon thread isn't all _that_ terrible), but I figured better to focus on correctness first. :) Pete

On 28/03/2011 01:11, Peter Duniho wrote: > On 3/27/11 3:41 PM, Martin Gregorie wrote: >> On Sun, 27 Mar 2011 14:19:52 -0700, Peter Duniho wrote: >> >>> On 3/27/11 2:12 PM, Peter Duniho wrote: >>>> [...] >>>> I don't see why you're seeing the DatagramPacket length [...] >>> >>> Er, "setting", not "seeing". Sorry if that was confusing. >> >> Maybe I'm stupid, but I don't see any way out of the inner 'while(true)' >> loop. If you're relying in an Exception to escape, at least document that >> in a comment. > > I don't think you're stupid. Actually, I'm pretty certain you're not. :) > > Short of shutting down the network adapter, I don't see any way in that > code to force an exception (e.g. closing the socket). Presumably there's > code elsewhere to do the ugly "abort thread" thing. Or maybe it's a > daemon thread and the OP is planning to just let it run indefinitely. > > Not my preferred means of managing i/o threads (well, okay…actually a > daemon thread isn't all _that_ terrible), but I figured better to focus > on correctness first. :) > > Pete Yes, it's running in a thread of its own that lasts as long as the app is active. The problem might be with the Android emulator. I can send packets but I'm not getting anything back. The Windows firewall is open on the correct port. -- Dirk http://www.neopax.com/technomage/ - My new book - Magick and Technology

Another problem with this code is that you need to set the packet length every time around the loop, before you read: not just once. Otherwise the datagram shrinks to the length of the smallest received packet.

On 28/03/2011 03:38, Esmond Pitt wrote: > Another problem with this code is that you need to set the packet length > every time around the loop, before you read: not just once. Otherwise > the datagram shrinks to the length of the smallest received packet. > Thanks -- Dirk http://www.neopax.com/technomage/ - My new book - Magick and Technology

On 3/27/11 6:47 PM, Dirk Bruere at NeoPax wrote: > [...] > The problem might be with the Android emulator. > I can send packets but I'm not getting anything back. > The Windows firewall is open on the correct port. Well, you can always implement each other end in a different way (e.g. C++/Winsock receiver, and a plain, non-Android/non-emulated Java sender) to double-check the work of each. At least, that's what I'd do in terms of diagnosis. I'll also suggest using Wireshark, but frankly very time I use it I find myself muttering to myself about how awkward it is to use. It's powerful, but hardly simple (and I never have gotten it to work properly on my Mac). For most network issues I've had to deal with (i.e. never really anything all that complicated), simple test apps have always sufficed to identify the issue, whether they are in my own code or in some other component I'm using. Pete

"Peter Duniho" <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote in message news:hPydnfmXd7OOYBLQnZ2dnUVZ_judnZ2d@posted.palinacquisition... > On 3/27/11 6:47 PM, Dirk Bruere at NeoPax wrote: >> [...] >> The problem might be with the Android emulator. >> I can send packets but I'm not getting anything back. >> The Windows firewall is open on the correct port. > > Well, you can always implement each other end in a different way (e.g. > C++/Winsock receiver, and a plain, non-Android/non-emulated Java sender) > to double-check the work of each. > > At least, that's what I'd do in terms of diagnosis. > > I'll also suggest using Wireshark, but frankly very time I use it I find > myself muttering to myself about how awkward it is to use. It's powerful, > but hardly simple (and I never have gotten it to work properly on my Mac). > For most network issues I've had to deal with (i.e. never really anything > all that complicated), simple test apps have always sufficed to identify > the issue, whether they are in my own code or in some other component I'm > using. I've only had to use Wireshark's full power once, but it was invaluable. The issue was HTTP requests being processed twice. The problem turned out to be that different sides of an HTTP connection had very different keepalive and timeout settings. The result was (from memory, so probably not exact): Sender sends a request on a reused TCP connection Receiver takes a long time to acknowledge the request Sender decides the TCP connection is dead, creates a new one and uses it to resend the request Receiver processes both requests I might have figured it out eventually, but looking at the packets going back and forth made it pretty obvious.

On 27/03/2011 21:37, Dirk Bruere at NeoPax wrote: > Got a bug somewhere... > Is this bit of code going to cause problems ie the bit running in the > loop? I find that the code never exits ds.receive(incoming) > > > try > { > DatagramSocket ds = new DatagramSocket(Constants.LOCAL_PORT); > DatagramPacket incoming = new DatagramPacket(receiveBuffer, > receiveBuffer.length); > incoming.setLength(60000); > > > while(true) //Run this as an endless loop > { > ds.receive(incoming); > packetStr = new String(receiveBuffer, 0, incoming.getLength(), "UTF-8"); > if (packetStr != null) BlinkAPI.update(packetStr); > } > } catch (IOException e1) {} > Nothing wrong in general (apart from the bug picked up by Esmond). As soon as I tried it on real h/w instead of the emulator it worked fine -- Dirk http://www.neopax.com/technomage/ - My new book - Magick and Technology