UDP Receive Block Error

While trying to try the example within UAV Simulator matlab throws the following error. http://www.uavcontrol.org/UAV_control/UAV_Control/UAV_Control.html

Error in 'example/X-Plane Comunication/UDP Receive': Only one usage of each socket address (protocol/network address/port) is normally permitted

It throws it twice and seems to indicate some sort of duplication. Has anyone else had this error? I think there may be some sort of configuration issue as whenever I start the simulation this error happens and also ans = 127.0.0.1 is printed in the command window of matlab.

I think therefore that there is some sort of network setting that is defaulting to 127.0.0.1 na dis being confused by my computers network settings.

[Walter Roberson]

127.0.0.1 is to be expected as the network address. udp would be the protocol. The problem would therefore be in duplicating the port numbers.

[Jonathan Pelham]

127.0.0.1 is not my network address however. I use a university computer on a network. My IP is dynamically assigned each time the PC starts up.

Is there some way to work out whether the socket is being used by something else and shut that down? Examining the Simulink model only shows one UDP receive block.

[Walter Roberson]

127.0.0.1 is a reserved address known as "localhost" which always means "this very computer". It is a way that you can exchange information between programs on a computer without having to know the external network address.

You can use netstat to examine network connections.

[Jonathan Pelham]

Unfortunately this doesn't solve the UDP Receive block duplication issue. I've attached a screenshot of the error message. I've reset the IP address in the simulation to 127.0.0.1 but I'm still getting this issue.

[Stephan Finn]

Any resolution here? Have the same issue with Simulink 2015b's DSP UDP Receive Block -> even if I generate a executable from which is containing a UDP receive block and try to start this executable twice, the "socket already used error shows up".

I would expect, that it should be possible to listen to a UDP broadcast port with multiple executables. I think there is a configuration leak or implementation error in the UDP receive Block...

[Walter Roberson]

Even with UDP, the system calls involved permit reserving the port for exclusive use. The system calls permit UDP to operate in Datagram Mode (for which it is expected that there might potentially be multiple receivers of the packet) or in Connection mode (for which it is not expected that there might potentially be multiple receivers of the packet.) Connection mode has lower per-packet overhead, and operates more like a data queue; for datagram mode, if your code does not happen to be waiting listening for a packet then it will not receive any packets that might fly by.

UDP does not have a broadcast mode any more than TCP does.

It is possible for a UDP packet to be addressed to the broadcast IP address on the IP network; for example for 192.168.1.* the broadcast IP address is 192.168.1.255 and a packet specifically addressed to that should be read by all 192.168.1.* systems. There is no routing permitted on packets that are addressed that way; it is a MUST NOT requirement prohibiting them from being routed.

There are, however, UDP multicast groups, which the destination system must specifically subscribe to.