I'm using Game Maker: Studio and already got the UDP broadcasting to work, but only for people using the internet in the same router. But, I want to broadcast via Hamachi too, so there's no need to enter the IP manually.
This is the function I can use: http://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_send_udp.html
And this one I use for local broadcast: http://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_send_broadcast.html
Your gamemaker UDP packets are as good as any other. So if you can send ping requests to an IP, you should be able to send it any UDP packet you want.
When you ping an address through hamachi, you are actually sending UDP packets to it. So if you want to know if UDP communication will work through hamachi, try to ping someone with the console (type "ping [his IP]"). If it works, then any UDP packet with he correct address should travel correctly, including the ones emitted by your gamemaker app.
Be aware, though, that you may have to cope with a greater packet loss ratio than on your local network. Contrarily to TCP, UDP packets may sometimes not reach their destination.
Related
I have made an UDP client server program in java. It is working well in localhost and in the same router/ network.
But when I am running my UDP server program in my laptop connected to internet and running my UDP client program in my lab (on different network), then it is not working.
Is there any way to send UDP datagram over the network from one system to another?
Yes, in theory it should be working just the same. It's still IP.
In reality, routers with NAT exist. For example, if you address an UDP packet to your home PC's public IP address, it actually is addressed at your router. The router does not know which local IP he should address the packet to and discards the packet.
The solution: Configure UDP port forwardings for routers on both ends.
I want to develop a P2P Gaming application. What is the fastest and efficient way to implement NAT traversal and Peer discovery. I have read about STUN and TURN server. But what are the Open source parts available and how can I use them?.
1. Does those STUN server work on 3G networks?
2. Does UDP HOLE PUNCHING works on 3G networks?
If you have a videogame, you probably want to have a central server that contains all the game data and allow the users to be clients. You know, like Puzzles and Dragons, where you have a username and password and sign in to a server.
Google "Stun Client" and "ICE protocol". There are plenty of open source implementations
STUN fails on mobile networks because mobile networks have symmetric, large scale NAT. Traversing that kind of nat doesn't work with STUN (see reason below)
Why Mobile Broadband NAT cannot be bypassed?
It boils down to statistics. In order for a connection to be established, you have to send a packet into the port that they are at and they have to send a packet into the port that you are at. If you send to the wrong port number or they send to the wrong port number, you miss and no connection is established. If both of you simultaneously bind to a port and send out a packet directed at the other's ip address, you have a 1 in 65535 (65535 being the number of port on an ip address) chance of sending a packet into their port and they have a roughly 1 in 65535 chance of sending a packet into your port. So the chance of you establishing a connection is (1/65535) * (1/65535), or (1 / 65535^2).
You can't know your port number for any subsequent connection because for every new outbound connection, the router randomly gives you a new port number on the interval between 1024 and 65535. So if you ask a server what you ip and port number is, it may tell you the right ip (your ip address doesn't change very often unless you turn off your phone or something like that), but the port number will change. If you try to guess the port number there is a ( (65535-1024-1) / (65535-1024) ), or 99.998% change of you guessing it wrong, assuming that the number of possible port numbers to choose from is (65535-1024).
So unless the port numbers are predictable (which in many 4G networks they are not), you're hosed - no chance.
Your best bet is to use stun and not support evil routers.
I am trying to send a UDP packet to a device that is behind a NAT. Using a 3rd party program it is possible to send packets to this device no problem, and the packets show up in wireshark fine.
Using my own UDP client to send a packet to the device doesn't work... but if the device sends ME a packet, in the onReceive() method, sending directly back to the device in this method DOES work...but interestingly if I take the EndPoint and connect to this using a new UDP client, then it doesn't work again.
It seems like only when the device connects to me can I send messages downstream (like reverse connecting in TCP) and even taking the EndPoint as a reference to the 'connection' is not enough.
Can anyone think of reasons why I can't send directly to the device, even though I know it is possible to do so because the 3rd party software can do it?
Sending directly to other IP's such as my local computer works fine too, it is just this device that I cannot contact. My local computer is on an address like 192.168.10.2 and the device is on an address like 12.0.1.5 (when connected it creates its own LAN)
Many thanks
I have a program that broadcast UDP to my local network, and one host device would read this message and function upon it perfectly.
Now I want to do this job remotely, knowing that where is the reciever host I have a public static IP provided by the ISP, and for example I'm out side this network and I want to broadcast this UDP traffic to it through the Internet, is there any possible routing configuration that would allow this trafic to reach the local network and just explode there ?
And if not. Is there any other way that can make this trafic, instead of broadcasting to be directed to this receiver host directly ? That would require then only some port forwarding in my static ip router.
By RFC, broadcasts cannot be forwarded by routers. Plus, several ISP will filter out such packets anyway. Broadcasts are limited to the local subnet only.
I suggest you look into multicast instead.
I'm trying to transmit data in UDP datagrams into a client in external location to a pc in my local lan.
But my network is over a ADSL modem sending to a pc with Slackware, this pc redirect packages into other pcs.
I'm using socat to redirect UDP:
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
In LAN the conection is fine, but external IPs don't work.
Somebody help?
I don't think socat is the culprit, however consider to use stone instead of socat, because using a fork() for each received packet is a bit weird. Stone is called in your case like this (I think):
stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udp
Now why external IPs perhaps do not work. Sadly your text does not tell much about your setup, so I have to guess:
It depends on your firewall/modem/router if it is able to forward UDP packets. Usually, if you initiate the UDP requests from the inside, the router will open a NAT connection, which often means, that not only the source IP of the packets change, but the source port as well. As UDP is connectionless, UDP NAT connections usually time out very quickly, say after 5 minutes, if no data is transferred on them.
If the UDP must be opened in the opposite direction (from Internet to Intranet), the router usually discards all the UDP packets coming in from Internet, because it does not know where to forward them to. A router cannot just choose some arbitrary machine, this would be a security hole. So in the "Internet connecting to a machine behind the router" you must open the UDP port on the router and let it forward to the right machine. In that case packets sent from your internal machine will get their source IP and the source port rewritten, the machine on the Internet always will see the packets as coming from your router. So except for the additional rule in the router this case is the same as the outgoing case.
Note that there are several different ways how to make NAT (symmetric, etc.) and several methods on how to open a port on the router (Config, UPnP, etc.) so the ways to poke some holes into it always depends on your hardware capabilities. This all cannot be answered here.
Some other ideas what might go wrong as well:
Some UDP protocols encode IP addresses within the payload. In that case it is not enough just to forward the packets, you must change the payload as well to correct the IP addresses exchanged to enable all machines to talk together. Such UDP protocols are badly designed, anyway, because you never should assume that two arbitrary machines can directly talk with each other, so all good protocols should support easy proxying.
Some ISPs filter certain UDP ports, for arbitrary reason. If you have problems talking from Internet to your DSL, try with two external machines directly connected to different ISPs. If these can talk via UDP check if you can talk from your Intranet to one of the external machines. If this still works, this means, that you can talk backwards as well, as usually UDP is not a directed protocol, but if there is some NAT involved you somehow must make sure that the communication ports stay open.
Mobile Internet plans often do not support P2P. This probably means, those plans do not support Internet at all, as IP, by definition, is P2P. What the ISPs really want to say with "no P2P" is (my guess), that connections from Internet to the mobile device are not supported. In that case you always must initiate a connection from the mobile device, so you cannot use push methods (Internet to Mobile), the mobile device always must pull (data from Internet). Some broadband/cable providers might do the same. Usually you can see this if your ISP hands out an IP in the 10.x.y.z range to you.
There might be another trick how to get the connection working:
Ask your ISP to get some IPv6. Perhaps use 6to4. With IPv6 you eliminate NAT completely, your local LAN then directly interconnects to the Internet on IPv6. Be sure to activate your firewall/iptables on your Intranet host on the IPv6 interface, else you might see Intruders very quickly.
HTH