Develop Reference

UDP messages from Java are received only on first run

I'm using Java's DatagramSocket to send UDP messages from Java to a specific port on my localhost. I listen to this port with netcat: nc -ul 9122.
On the first run of my Java code (after starting nc) - the message is received and displayed on my shell. On each other run - messages are not received. Only restarting nc will do.
This is my Java code:
public static void main(String[] args) throws IOException, InterruptedException {
byte[] buf = "Hi There\n".getBytes();
InetAddress address = InetAddress.getLocalHost();
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, 9122);
DatagramSocket datagramSocket = new DatagramSocket();
datagramSocket.connect(InetAddress.getLocalHost(), 9122);
if(datagramSocket.isConnected()) {
datagramSocket.send(packet);
Thread.sleep(500);
datagramSocket.send(packet);
Thread.sleep(500);
datagramSocket.send(packet);
}
}
What do I miss?
Thanks

This seems to be a feature of ncat. After receiving one UDP packet, it only accepts packets from the same origin host and port. It is similar to a connection: an instance of ncat only handles packets from a single client.
When you start the Java program, it will select an arbitrary local port, and when you restart it you will get a different port. You can set fixed local port by passing it to the DatagramSocket constructor:
DatagramSocket datagramSocket = new DatagramSocket(12345);

Java - getting IP address of server listening on a port

I have a server listening on a certain port for client request.. Ex. 9000
Now my client doesn't know the server ip but knows the port to send requests.. How do I know from the client side what is the IP of the server on listening on that certain port?
Both server and client is on the same physical network..
The server always listen on port 9000 for any clients request..
The clients send requests to the server and expects a result...
Sometimes the server changes IP (because of DHCP).. So i want my client to know the server IP when it change...

You can think of the IP address and the Port as the street address of a house (≈ IP address) and an apartment number (≈ Port). Deducing the IP address from a Port number is just as impossible as deducing a street address from an apartment number.

If the nodes are in the same local network (same address class and no router in between),
you should use a UDP broadcast to make a "network discovery".
Schematically:
- The client broadcasts a call and wait for response.
- The server receive the call (the UDP boradcast call do not needs an IP address, only the port is required)
and answer to the client (do some handshake).
- The client receive the UDP packet, it contains the IP address of the sender node (the server).
Client Side:
public void broadcastCall(){
try {
//Open a random port to send the package
DatagramSocket c = new DatagramSocket();
c.setBroadcast(true);
byte[] sendData = "DISCOVER_SERVER_REQUEST".getBytes();
/*
* Try the 255.255.255.255 broadcast
* (or use the boradcas address of you network class like 192.168.1.255)
* port 9100
*/
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length,
InetAddress.getByName("255.255.255.255"), 9100);
c.send(sendPacket);
System.out.println(getClass().getName() + ">>> Request packet sent to: 255.255.255.255 (DEFAULT)");
//Wait for a response
byte[] recvBuf = new byte[15000];
DatagramPacket receivePacket = new DatagramPacket(recvBuf, recvBuf.length);
c.receive(receivePacket);
//We have a response
System.out.println(getClass().getName() + ">>> Broadcast response from server: " + receivePacket.getAddress().getHostAddress());
/*
* NOW you have the server IP in receivePacket.getAddress()
*/
//Close the port!
c.close();
} catch (Exception e) {
e.printStackTrace();
}
}
Server side:
public void broadcastResponder() {
try {
/*
* open receive datagram broadcast socket port 9100
*/
DatagramSocket socket = new DatagramSocket(9100, InetAddress.getByName("0.0.0.0"));
socket.setBroadcast(true);
System.out.println(getClass().getName() + ">>>Ready to receive broadcast packets!");
//Receive a packet
byte[] recvBuf = new byte[15000];
DatagramPacket packet = new DatagramPacket(recvBuf, recvBuf.length);
socket.receive(packet); // This method blocks until a datagram is received
//Packet received
System.out.println(getClass().getName() + ">>>Discovery packet received from: " + packet.getAddress().getHostAddress());
byte[] sendData = "DISCOVER_SERVER_RESPONSE".getBytes();
//Send a response
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, packet.getAddress(), packet.getPort());
socket.send(sendPacket);
System.out.println(getClass().getName() + ">>>Sent packet to: " + sendPacket.getAddress().getHostAddress());
// close socket
socket.close();
} catch (Exception e) {
e.printStackTrace();
}
}

Why UDP hole punching does not work for public IP address?

There are two Groovy sub programs below sending messages to each other via plain UDP sockets. They does receive the messages successfully when they are sent to 127.0.0.1. But the messages aren't received when sending them to the public IP address (the machine is behind NAT).
Why the hole is not punched? And how to fix that?
I tried querying a public STUN server via a Java library earlier but it responded with the same public IP address to me, so I use wtfismyip.com here.
class GroovyTest {
static String PUBLIC_IP = new URL('https://wtfismyip.com/text').text.trim()
//static String PUBLIC_IP = '127.0.0.1' // works fine
static void main(String[] args) {
runInstance(11111, 22222)
runInstance(22222, 11111)
}
static void runInstance(int thisPort, int anotherPort) {
def socket = new DatagramSocket(thisPort)
Thread.start {
// message listener
byte[] buf = new byte[1024]
while (true) {
DatagramPacket packet = new DatagramPacket(buf, buf.length);
socket.receive(packet);
InetAddress remoteAddr = packet.getAddress();
int remotePort = packet.getPort();
String sentence = new String(packet.getData(), 0, packet.length);
println("server-$thisPort: received [$sentence] from ${remoteAddr.hostAddress}:${remotePort}")
}
}
Thread.start {
// message sender
while (true) {
println("client-$thisPort: sending to ${PUBLIC_IP}:${anotherPort}...")
byte[] buf = ("Hello " + System.currentTimeMillis()).bytes
DatagramPacket packet = new DatagramPacket(buf, buf.length, InetAddress.getByName(PUBLIC_IP), anotherPort)
socket.send(packet)
Thread.sleep(2000)
}
}
}
}

Your problem stems from the fact that the IP address returned by wtfismyip is the IP address of the router on your network, which is not assigned to your computer. When you try and send a datagram to your router's public IP you'll probably get and ICMP Destination Unreachable error message from your router. If you need this behavior, your router may have some port forwarding capabilities that can forward inbound UDP traffic to your local IP address.

I have been successfully replying to UDP packets behind a NAT router by simply taking the address and port details from the UDP packet I'm responding to...
DatagramSocket socket = new DatagramSocket(port);
DatagramPacket receivePacket = new DatagramPacket(receiveBuffer, receiveBuffer.length);
socket.receive(receivePacket);
DatagramPacket sendPacket = new DatagramPacket(sendBuffer, sendBuffer.length,
receivePacket.getAddress(), receivePacket.getPort());
socket.send(sendPacket);
The code is more robust in that it doesn't matter where the packet came from, or any address translation which occurred along the way. It will always reply to the right place.
I'v also noticed you are using two different port numbers. "thisPort" and "anotherPort". As far as I know, the hole punching will only work if you reply on the same port number. This makes sense for security reasons.
The marine robot on top of my head, pictured in my avatar, uses this UDP hole punching technique.

Android UDP works only inside Home net

I have UDP server and client, my code works inside home with internal IPs such as 192.168.0.X. If I put my code inside my online server with external IP (X.X.X.X) server receives and send but Android can only send and doesn't receive. What is the problem?
Android send code :
byte[] sendData = new byte[1024];
try {
DatagramSocket serverSocket = new DatagramSocket(1500);
InetAddress IP = InetAddress.getByName("My server IP");
String invia = "I am Android";
sendData = invia.getBytes();
DatagramPacket send = new DatagramPacket(sendData, sendData.length, IP, 1500);
serverSocket.send(send);
}
Android receive code :
byte[] receiveData = new byte[1024];
try {
DatagramSocket serverSocket = new DatagramSocket(1600);
while (true) {
DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
String sentence = new String( receivePacket.getData());
Log.i("FROM SERVER:", "" + sentence);
}
} catch (Exception e) {
}
Server code :
DatagramSocket serverSocket = new DatagramSocket(1500);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
/** receive **/
DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
String sentence = new String( receivePacket.getData());
System.out.println("RECEIVED: " + sentence);
/** send **/
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
sentence = "I am PC";
sendData = sentence.getBytes();
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 1600);
serverSocket.send(sendPacket);
}

Why does it not work externally, yet it does locally ?
You have to understand NATPAT.
Even running a webserver on your home pc will not work.
When you browse with your browser, you are taking initiative and send a GET to a server using its IP# and port. Your local IP# behind the NATPAT router is not unique across the internet, it is unique only behind your router. So your local ip# of your pc cannot be used to talk to the server. So your router is going to build an internal table based on your local ip# and local port and a port he allocates himself, he then forwards your request to the webserver you want to talk to but using your public ip# and that allocated port. when the server replies he is going to reply to your public ip# and that allocated port. Your NATPAT router sees the reply and know ah it is a reply on that allocated port, it looks in his internal table and forwards to the local ip# and local port that he remembered in his lookup table.
If you host a server behind a NAT PAT router, you cannot get any incoming messages to your webserver because the table is empty.
And that is the problem with your android listening on port 1600. He never sent anything on that port and ip# so your router does not know for whom it is.
It works locally because then all your local ip# are used that your DHCP enabled router has assigned to your devices. And there is never any translation needed to the public IP# that your ISP has provided you with.
Read this :
http://searchnetworking.techtarget.com/definition/Port-Address-Translation-PAT
and this :
Following is an illustration. Let's say the ISP Public IP address is 3.12.62.154. The objective is to run public-accessible web server that run on standard protocol TCP port 80 (the web port). The local network Private Subnet is 10.0.0.0/24 where the server IP address is 10.0.0.10. For the public access, the 10.0.0.10 will be PAT-ed to the 3.12.62.154 on TCP port 80.
When users on the Internet try to connect to the public web server, those users connect to the 3.12.62.154 IP address and not to the 10.0.0.10 IP address. The reason is that on the Internet, the web server is seen as the 3.12.62.154 IP address. The 10.0.0.10 IP address is only seen within local LAN.
from here : http://www.dslreports.com/faq/13449
If you don't understand any of this, stop trying, start reading instead.

Broadcast server discovery

I'm creating a game in Java that simulates the classic 5 cards Poker with 2 to 4 players.
Most of the data will be processed by a server, but since I can't use an online server, my idea is to allow a user to host a game by creating a local one.
Now, I don't want to force the use of IPs to connect to a game, so I created a "discovery" interface within the user can see all avaible games. This is done using the UDP protocol and a broadcast research on a common group:
(code is simplified to show only the actions that are executed, may not work as it is showed here)
Client
MulticastSocket socket = new MulticastSocket(6020);
InetAddress group = InetAddress.getByName("226.0.0.1");
socket.joinGroup(group);
DatagramPacket packet = new DatagramPacket(new byte[] {(byte) 0xF0}, 1, group, 6020);
socket.send(packet);
while(true) {
buf = new byte[1];
packet = new DatagramPacket(buf, buf.length);
socket.receive(packet);
if(packet.getData()[0] == 15) {
Socket client = new Socket(packet.getAddress(), 6020);
}
}
Server
MulticastSocket socket = new MulticastSocket(6020);
InetAddress group = InetAddress.getByName("226.0.0.1");
socket.joinGroup(group);
// new thread listening on port 6020 TCP
ServerSocket server = new ServerSocket(6020);
new Thread(new Runnable() {
public void run() {
while(true) {
// new thread communicating with client and back listening on port 6020
new ServerThread(server.accept());
}
}
}).start();
// listening on port 6020 UDP
byte[] buf;
DatagramPacket packet;
while(true) {
buf = new byte[1];
packet = new DatagramPacket(buf, buf.length);
socket.receive(packet);
if(packet.getData()[0] == -16) {
DatagramPacket packet = new DatagramPacket(new byte[] {(byte) 0x0F}, 1, packet.getSocketAddress());
socket.send(packet);
}
}
The client sends an UDP broadcast packet on the port 6020. When a server receive this packet if it's composed by a byte 0xF0, he sends back a byte 0x0F to the client. Every client is also listening on the port 6020 and when receive a packet composed by a byte 0x0F it starts a new connection TCP to the server on the port 6020.
My question: is there a better way to achieve this "discovery" system?
I know this is going to work only in local networks, is it possible to extend the discovery "outside" using a local server?

Unless you want to set up some sort of known broker that can connect players with servers (or give them a listing of servers), you may be out of luck. As you discovered, multicast and broadcast is generally not sent to the WAN by most switches (and definitely cannot traverse the Internet).
If your issue with setting up a known server/broker is that you have a home connection and so a dynamic ip, I would recommend looking into dynamic DNS. There are a number of providers out there that will allow you to set up a sub-domain on their system that is automatically changed to point to your IP as your IP changes.