Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 6/03/2014 11:42 AM, Art Botterell wrote:
> Yes, maybe I should have called that out specifically, but I figured somebody would ask. ;-)  Like all the rest it's just a suggestion.
True, but I was pointing out at this early stage, it's probably best to 
keep as open and general as possible.
>
> My thinking, for whatever it might be worth, is as follows:  We're going to have multiple network connections going simultaneously... control data, and various forms of streaming analog and/or digital media TBD.  Wrapping them together in a single VPN session means there's only one port to clear through firewalls.  It also meets our encryption requirement.  And it lays the groundwork for more sophisticated architectures in the future... e.g., clustering multiple stations via a shared VPN server for diversity.
Are these our goals?  Firstly, I can see 50-90% of stations being single 
PC (with network connections over 127.0.0.1 or ::1 - more likely the 
latter with modern OSs).  Up to 99% will be single site (i.e. the one 
physical LAN).  Do these need encryption?  Even my station will be one 
physical LAN, and when they can't, the devices I'd be using can't run 
OpenVPN (but I can and do use thr native IPSec support on them and the 
router already).

What effect will mandatory encryption and the encapsulation of all 
protocols into one data stream have on latency?  What about network 
topology, especially on a LAN?  The implementations of OpenVPN I've used 
have required extra IP addresses and subnets, all a bit overkill and 
messy.  And what of the other goal of IPv6 capability?

Not nit picking, just throwing other considerations into the mix, that 
might have a bearing on how things are done.  Again, I wonder if this is 
better handled as an optional "WAN module", which can be optimised for 
latency and also offer audio compression, as well as encryption and a 
higher level of security, and turned on when needed for distributed (non 
remote base) stations.  Also, licensing, if we're using external code.  
Hmm, OpenVPN is GPLv2, by the looks of it, which would be an issue if we 
wanted to use code, given one of our goals was to release under a BSD or 
similar license (to allow for adoption by both free and proprietary 
vendors without disclosure of source).
>
> Note that a VPN doesn't actually specify any of the individual link protocols... it's just a wrapper that lets us handle routing and encryption issues once instead of repeatedly.  And I only specified OpenVPN because... well, it's open.
Agree, and the methodology could be used in a different way too.
>
> I'm sure there are other ways to meet our requirements although personally I don't know of a more convenient one.  Open to suggestions, as ever.

Interestingly, seems there is now an iOS port of OpenVPN in the iTunes 
App Store, that's a relatively recent development (pardon the pun!).  
Still, IPSec has been the most convenient lately, because it's built 
into my devices and router (and seems to work quite well).  It's been a 
while since I had a Linux box on the edge of my network, too many cheap, 
convenient and power saving routers around these days.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com