UDP socket send receive

[think2]

I'm writing some embedded Linux software where we have two microprocessors on the same PCB and they communicate with each other using UDP through a switch that is embedded on the PCB. Each application has a hard coded IP address. I want to use non blocking send and receive and I found some example code here
udpClientNonblock.c
and
udpServer.c

Why does one of them have to be a server? I want to do peer to peer communication between the two microprocessors. Can both of my embedded applications use udpClientNonBlock.c style code or does one have to be a server?

It seems the difference between server and client is that server calls bind(), listens for all incoming IP addresses and doesn't seem to be non-blocking on receive. Neither the server or client know their own IP address and in the sendto message sent by the server, it uses a destination IP address that came from the incoming recvfrom function.

The target code runs on Linux but I want to test it on Windows first. Is it possible to have two applications running on the same PC that talk to each other using UDP ?

In the client code in the example above, a port number is specified as part of the server address and the server listens on that port. In the client code recvfrom function, does the client receive all messages regardless of the port number or only from the port specified as part of the server IP address ?

 

[Cogman]

Why does one of them have to be a server?

How else would you coordinate? One will have to connect to the other, so determining who listens (the server) and who connects (the client) is somewhat of a necessity. You could have both listening and both connecting, but that would establish 2 connections which you probably don't want.

The code for both the server and client to write and receive data is basically the same once the socket is established. The only real difference is who establishes the connection and who waits for a connection.

Is it possible to have two applications running on the same PC that talk to each other using UDP ?

Yup, happens all the time. Heck, when I'm developing I almost always launch a an application locally and hit it. This is what "localhost" is for.

In the client code in the example above, a port number is specified as part of the server address and the server listens on that port. In the client code recvfrom function, does the client receive all messages regardless of the port number or only from the port specified as part of the server IP address ?

When the client establishes a connection with the server, it opens a new port. That port comes from the OS and is not the same port number that the client connected to. The client application will only receive messages sent to that new port that the client opened up.

So, for example, lets say your client wants to talk to server port 8080. It will open up a new port, lets say 50292 and will connect to the server port of 8080. All messages from the client will go to the server with a port number of 8080, all messages from the server will go back to the client with a port number of 50292.

The port number is used by the OS to determine which messages should go to which application. The IP address gets the message to the right machine, the port number gets it to the right application.

As a fun side note, NAT screws around with this which can make things difficult at times. NAT will make a virtual port number for the internal IPs. So, your client would have 50292, the NAT server would assign 56940 as the port number, which is what the server sees. The server will sent a response to 56940 which the NAT uses to say "Oh, that actually goes to IP 192.168.0.123:50292" and forwards the message on to the right machine.

A LOT of people hate this because the NAT server has way too much visibility in what should be an application level concern.

IPV6 fixes this because you shouldn't need NAT anymore (everything can get it's own unique IP address)... however, the rollout of that has been terribly slow.

 

[think2]

Awesome, thanks a lot.

I found some code here
stackoverflow

where both ends of the UDP connection are doing bind and connect.
Supposedly making a permanent connection is more efficient.

Does that look like a reasonable way to do it?

 

[Cogman]

This is reasonable but realize that they are creating 2 connections instead of just 1. The most efficient network utilization is to have 1 permanent connection. Having 2 connections isn't bad and works, it is just not 100% efficient.

Where this is UDP, it probably hardly matters. TCP would be more of a problem due to TCP slow start.