Home› AMX User Forum› Duet/Cafe Duet
Options

UDP Datagram Sockets

ipssheldonipssheldon Posts: 106
in Duet/Cafe Duet
Has any one used Datagrams to send UDP packets with Java or Duet? I'm having an issue changing the setTimeToLive parameter associated with Datagrams. In Netlinx (and maybe Java), the default value is 1 which means that broadcast packets (to addresses like 192.168.15.255) are thrown away after 1 hop in networking switches/routers. In many cases, this is not sufficient. Java has support for changing this value, but I've yet to get my code to work. I can post the code or handle this offline if anyone has tackled this issue before.

Just curious before I bore everyone with a long post.

Thanks in advance.

Comments

  • Options
    travtrav Posts: 188
    TTL

    The broadcast will not propogate through a router, it should go through the switches though.
    The UDP Broadcast is limited to the subnet it is on, and routers will not route a broacast.

    A TTL should only be decremented by a router in anycase, so I'm a little confused.
  • Options
    ipssheldonipssheldon Posts: 106
    The TTL value is decremented for each hop. But if the value starts at 1, then the message can only be routed to the same subnet of the sending device. If the TTL is something greater than 1, then the sending device, such as the Netlinx master, can send a packet to another subnet, and if the IP is a broadcast address, such as 192.168.65.255, then the message will be broadcast to all devices on the 65.x subnet. On a broader scope, the same would occur with a multicast address (above 224.0.0.1). But if the TTL is fixed at 1, then you don't even have the option to route a message beyond the same subnet.

    Java provides the mechanism to change this. I just haven't been successful in getting the code to work. I was hopeful that someone might know what I'm doing wrong.
  • Options
    jweatherjweather Posts: 320
    Directed broadcasts are blocked by default in modern routers, as it is a security and denial-of-service hazard. Unless you're specifically enabling directed broadcasts on the routers you're passing through, it's not going to work.
  • Options
    Spire_JeffSpire_Jeff Posts: 1,917
    I wish I could help more, but I think Sheldon is saying that he is aware of what is needed on the network side and he can adjust that accordingly. The problem is that he cannot change the TTL on the packet, so that even after setting up the network to allow the packets to go where they are needed, the TTL prevents this. Think of a tracert. Tracert is really just just sending 3 pings with a TTL of 1, then 3 pings with a TTL of 2, and so on. No matter what is configured on your router, if you try to ping yahoo.com with a TTL of 1, you will never get a reply (unless you are yahoo.com :) ).

    Jeff
  • Options
    ipssheldonipssheldon Posts: 106
    Well, the good news is that I've solved my problem. Or at least, I believe that it's solved. A suggestion from a Java user forum suggested that I simply use "MulticastSockets" instead of "DatagramSockets". It seems that MulticastSockets do everything that a DatagramSocket does, plus gives direct control of setTimeToLive.

    The strange thing, however, is after implementing MulticastSockets, I was still not able to route between broadcast addresses to a single subnet (addresses such as 192.168.65.255), but I am able to use a multicast address, such as 224.1.1.100.

    The other strange result is that after I made this change, even setting the TTL to a value of 1 still works. So, I may simply have too flat a network to do a true test. But since MulticastSockets give me direct control of the TTL value, this hopefully, won't be a problem in the field. I'll have to work on my network to get a better setup so that a TTL of 1 fails to route packets, but values greater than 1 do route messages.

    Jeff was accurate in his comments, as well. For broadcast messages, the TTL determines how many hops the networking devices will propogate a message. Messages to a direct IP are not affected, only broadcast messages (x.x.x.255 and multicast messages above 224.0.0.1).

    Thanks for the replies.
Sign In or Register to comment.