Originally Posted by Hakan
Your comment: ".....udp packet to be received by multiple sockets " can be valid if you refer to two or more portable instances.
Apologies if I am misunderstanding your scenario. Last time I looked at the OpenCPN
code (admittedly last beta) any "transmitting" UDP data connection would also implicitly be receiving with the wildcard bind address. If you have your "main" OpenCPN transmitting on 127.0.0.1 it is also receiving. If you then have a second instance of opencpn on the same machine (receive only) you have 2 udp sockets receiving on the same port, only one of which will receive the transmitted datagram.
, the datagram appears to be delivered to the last socket opened and listening on that address. This means that if you open your transmitting connection first it will "work". If you open the "listening" connection first it won't work (because data will be delivered to the "transmitter"'s listener. IIRC (someone please correct me if I'm wrong) reconfiguring data connections closes and re-opens them, so this might seem to stop an apparently "working" connection (by changing the creation order of sockets).
None of that matters with broadcasts which can be delivered to multiple sockets, but 127.0.0.1 is a unicast address.
Of course I could be completely wrong: As I said I know nothing about Windows and this is something that could be very platform dependent: I would guess that the implementation of "localhost" is different on windows.
Did you try 127.255.255.255 as a transmit address? Probably won't won't work as Windows might well not implement localhost as a broadcast-capable interface.
Windows networking experts chip in now :-)