OpenCPN Beta Version 3.1.1309 Released

[Hakan]

Muttnik..
Thanks, nice discussions.
We thus have to sittuations. One with a assigned IP address when a network connection is available. Then it's not a at all a problem and I don't need the 127.0.0.1 address. Then I use a generic sender address like 192.168.x.x. Surprisingly, at least for me, the "x" is in fact working. Still the reciever is only watching the port 10110. No address assignment needed. That communication is clear as a bell and never fails.

The other task is, as earlier discussed, when no network connections are established. Then windows won't see any address at all. No matter if the cards have a static address given or not. So in that case I've to use something generic. And looking in the systems net table then the 127.0.0.1 and 0.0.0.0 are present. The first is working even if the connection sometime needs a portion of patience to trigger initiation. The latter is not working. '

Your comment: ".....udp packet to be received by multiple sockets " can be valid if you refer to two or more portable instances. That I haven't tried and don't neither need. It's ok if can have one extra window in addition to the ordinary OpenCPN window. But on the other hand... the sender itself is also listening to incoming traffic to port 10110 thus it's echoing back in what's sent out.

Håkan

[muttnik]

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.

On Linux, 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 :-)

[Hakan]

Muttnic..


Yes if I remember right I tried 127.255.255.255 without success.
And referring to http://whois.arin.net/rest/net/NET-127-0-0-0-1 I think 127.0.0.0.1 is the one to be. (Correct English??)

Your comment of opening orders dependency can be valid. I'll try and see if there is any logic to sort out there.
Coming back. /Håkan

[petermoree]

Dave, I find it difficult to click on the tide icon to get the tidal graph.

With *tides* ON
I go to the icon that shows falling or rising tides.
Then click on that icon to get the tidal graph.
This last action is often cumbersome (Possibly the sensitive area is to small)
Does the sensitivity area changes with the chart scale?
Whatever I test (at home on Vista) I often have trouble making the tidal graph pop up.

Kind regards

Peter

[muttnik]

Originally Posted by Hakan

Yes if I remember right I tried 127.255.255.255 without success.
And referring to http://whois.arin.net/rest/net/NET-127-0-0-0-1 I think 127.0.0.0.1 is the one to be.

Yes. 127.0.0.0/8 is a special block which must not be routed outside the host (RFC 1122). Generally hosts will define 127.0.0.1 as a node-scoped unicast IPv4 address (ie an internal address which loops back to the local host). This is not necessarily implemented like a regular interface and there is not necessarily an IPv4 broadcast address associated with the loopback interface (this will be OS dependent). On some platforms an IPv4 broadcast can be sent to 127.255.255.255 and picked up by multiple sockets listening on the same port and the wildcard address. On others this might not work, and I'm afraid I don't have the knowledge or tools to test this on windows and I've had a strange lack of success trying to google this