OpenCPN Beta Version 3.1.1224 Released

[muttnik]

Originally Posted by Hakan

Initially the UDP listener can/shall in all cases use IP address 0.0.0.0.
The UDP talker shall use IP 127.0.0.1 when broadcasting PC internally and something like 192.168.x.255 when connected to a network. (That's what the wiki now says)
In above cases all shall use the same port. (Wiki suggests nicely 10110)

I don't think I completely understood your set-up, possibly because I'm feeling a little fragile from New Year's eve still so please forgive me if this doesn't help or you know this already but perhaps the problem lies in a misunderstanding of what "0.0.0.0" means: there is ample scope for confusion. IP broadcast is a nightmare (which is why it's not even in IPv6). As a listener "address", 0.0.0.0 (aka INADDR_ANY) is a "wildcard" address. OpenCPN sets the socket to be able to receive broadcasts, so udp packets to the port you specify destined to the unicast or broadcast address of *any* interface (as well as 255.255.255.255) will be received.

When you tell OpenCPN to output to a particular address it will *send* to that address, but it will still *receive* on the unicast or broadcast address of *any* interface. Thus if you have more than one udp interface, things might not work on the receive side how you expect.

IIRC when I took a quick look at the code there was no way in OpenCPN for the user to specify binding to a particular address for receiving udp. Once you start going down that road things start getting rather more complicated so that may have been a conscious decision. They might also be a little restricted in what they can do by the class libraries they are using for networking (although I'm not in the least familiar with them).

Of course I could be completely wrong: this is just a guess.

[Hakan]

Hej. I thrust everything from New Years eve is forgiven for all of us with a happy smile. Welcome to 2013 and many thanks for the answer.

You don't understand??? So -- what about me? What I can see your knowledge is at least far more comprehensive than mine. I've, as you may noticed, very restricted experience with networking so my assumptions was a desperate result of trial and error. The listener address 0.0.0.0 was a try after a look in the port table by "netstat" and it happens to be the most reliable and repeatable way to obtain a connection. I understand that the 0.0.0.0 address is a wildcard in a more general way then 255.....255. But it worked and the UDP is if I understand it right a general way to broadcast. Anyhow.. your info was explaining why the echoing back to talker was interrupted as soon as the listener occupied the port. So why not use this when I want to broadcast within the same PC especially when a LAN IP address is not present? Or could it be that method causing the buffering when I later tested with a LAN and a proper LAN IP address?

Anyhow, again, the fuzzy trial and error setup was a result of very unstable connections. Please advice how I shall make it stable and still in connection with two open serial ports that seems to make it worse.

And I agree that we should not try to handle a "nightmare" in O', but make it as simple as possible. That use to be the best way of obtain functional things.

Again many thanks for your answer and patience. /Håkan

[Hakan]

Muttnic..
I did some more trials after your doubts about the 0.0.0.0 address. Instead I'd blanked the address field out for receivers. That was working nice both for local and LAN connections. For a local sender, where a IP address is not present I used 127.0.01 and 192.168.1.255 for LAN broadcasting. Also together with serials those where the most reliable so far. (See attached pic for a listener connection.)

[phiggins]

Should a plugin compiled on the latest version work on V3.0.2 ?

Is anyone thinking about this question?

Also, is it possible to "git" the 3.02 source again so I can recompile my plugins under that version?

[cagney]

Originally Posted by phiggins

Is anyone thinking about this question?

Also, is it possible to "git" the 3.02 source again so I can recompile my plugins under that version?

Paul
Yes I did!
I hoped that one of the developers would chip in....

Should a plugin compiled on the latest version work on V3.0.2 ?

No don't think so, as the beta series change log, shows a handful of changes to the plugin API.

The source code is available from the same place as the betas, but using the branch stable.

git clone -b stable https://github.com/OpenCPN/OpenCPN.git

This info is also available on the download page.

Thomas

[phiggins]

OK thanks Cagney. So that means we have to have two sets of plugins, one for 3.02 and one for versions after that...bummer

[cagney]

Originally Posted by phiggins

OK thanks Cagney. So that means we have to have two sets of plugins, one for 3.02 and one for versions after that...bummer

Paul

That's a bit of a jump in conclusion! Look at the present plugin download page, and the dates the plugins are released! At the same time almost no reports of plugin problems from beta testers (the odd exception yes). My conclusion is that plugins compiled for 3.0.2 works on 3.1.1224 just fine, which I'm sure is by design.
The reverse scenario that you asked about originally, is of course more complicated. You may have to wait for Dave to get the nitty gritty, for exact your plugin.

Thomas

[phiggins]

That's a bit of a jump in conclusion

Cagney, I have been working on computers for 45 years, probably before most of you were born, and this is the first time I have heard of a new version NOt being downward compatible but the old version being upward compatible.

[boraxtr]

I had claimed to resize the options window of the toolbar for the earlier version. (http://www.cruisersforum.com/forums/...ml#post1113185).

For the 3.1.1224 version, the options window even is resizable vertically but still not possible horizantally (from left to right or vise versa).

[Hakan]

Originally Posted by boraxtr

I had claimed to resize the options window of the toolbar for the earlier version. (http://www.cruisersforum.com/forums/...ml#post1113185).

For the 3.1.1224 version, the options window even is resizable vertically but still not possible horizantally (from left to right or vise versa).

Bora..
I not at all judging your opinions but I can express mine from a user’s point of view. It’s also possible I misunderstand all of it.
So, I can’t see the benefit of resizing horizontally. The bar adapts horizontal to let chosen buttons fit. If the O’ main window shrinks below the bar’s horizontal length a “carriage return” occurs and the bar divides to two rows. You can also put the bar in a vertical or horizontal row. If the bar is disturbing the chart view you can choose the Journeyman template with a more transparent appearance. What more can you need?

[boraxtr]

Originally Posted by Hakan

Bora..
I not at all judging your opinions but.... It’s also possible I misunderstand all of it.

Hi Hakan, Yes misunderstood... I mean the options window reachable from the toolbar. I mean resizing the options window not resizing the toolbar (picture attached at the above link). Resizing the option window as a user is very important since it limits to see the map at all.
Hasan

[bdbcat]

phiggins....

Lets get this right, please.
I apologize in advance for the numero-alphabet soup coming...

OpenCPN 3.1.x is downward compatible with all previously built and/or distributed PlugIns. You could also state this as the inverse: all older PlugIns are upward compatible with new versions of OpenCPN. This is a fixed design goal, and we have gone through some hoops to make this happen.

But, the opposite is not true. Plugins built to 3.1.x API spec are not compatible with OpenCPN 3.0.x. And the corollary: OpenCPN 3.0.x is not compatible with Plugins built to the 3.1.x API spec.

This second case should be clear., logically. How could OCPN 3.0.x anticipate what the the 3.1.x PlugIn API extensions would look like?

So, the model to follow is this:
If you want a durable PlugIn that runs on 3.0.x and runs on all subsequent versions, code to the 3.0.x API.

...unless...
You want the extended features provided by the 3.1.x PlugIn API, in which case you should use the 3.1.x API to create an Enhanced PlugIn, which will be compatible with 3.1.x and all versions to follow.


Cast it in the Windows model, for clarity. Win7 will run dlls created on Win98 (after a fashion), but Win98 certainly won't run many dlls distributed with Win7. Anything involving Unicode or OpenGL are good examples.

Hope this is clear.

Thanks
Dave

[bdbcat]

Folks...

To clear up some confusion regarding route and Waypoint upload functions...

Some of the below discussion has not been implemented in the current (3.1.1224) Beta, but will be coming very soon. Think of this as a preview for critical comment.

1. The output ports used by the route and WP upload functions available in the Route Manager Dialog (RMD) and in some context menus do not participate in any direct way with the Datastream multiplexer. The upload port does not need to be specified as an output-capable datastream. In fact, if the port is participating in the multiplexer scheme in any way, it is temporarily borrowed and removed from the multiplexer for the duration of the instant route/WP upload. You may choose any serial port you wish. Upload to network ports is not supported.

Reason for this arrangement: It would probably not be desired to broadcast route and WP information to all ports which happen to be listening to the multiplexed datastream. Imagine the confusion that could result in a complex environment. Rather, it is more likely that the intent is to send a route/WP definition to a single instrument. That instrument could later monitor and/or control the ships behavior as it works toward the route or WP.

2. The port to be used for uploads is specified directly in RMD by drop-down menu selections, and is sticky in that the last used port string is retained in the config file and will be selected as default for the next upload.

3.The "upload" item available in some context menus is intended to be a 2-click graphical shortcut for uploading a route or WP. The port used will be the last port specified in the RMD, or the first logical port list item if RMD selection has never been used. To avoid uncertainty, the next Beta will show that port name directly in the selectable menu item. So, if you find that the context menu upload is going to the wrong place, upload once in RMD. The next context menu (shortcut) upload will go to the same place.

I invite comments.

Dave

[bdbcat]

Hakan/muttnik...

OK, I'm lost in the fog of networking possibilities.

What are we doing wrong, and how could we be better?

Dave

[Gilletarom]

Hello,

Originally Posted by bdbcat

Folks...

To clear up some confusion regarding route and Waypoint ...
....
Reason for this arrangement: .... Rather, it is more likely that the intent is to send a route/WP definition to a single instrument. That instrument could later monitor and/or control the ships behavior as it works toward the route or WP.

I invite comments.

Dave

Dave, on this point, I totally agree with you.