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

[Art B. <ac...@in...>]

Tony -

Like they say in the investment ads up here, "Past performance does not predict future results."  The question I'm asking isn't how most hams have done things the in the past (answer: manually with no processors or networks at all) but rather how new and creative hams will want to do it in the future.

Anyway, IP conflicts are precisely what a VPN resolves, by creating... well, a "virtual private network"... with its own internal address space accessible at all connected locations.

Certainly I'm sorry to hear about your underpowered laptop.  Can't open a PDF in a web browser, really?  And yet it supports IPv6 and IPsec?    And you a computer-industry pro, too!  

Not sure what to suggest there, really... other than to mention that Raspberry Pi's are pretty cheap.  I really don't see any way we'll be able to move ahead with a project at this level of sophistication without being able to refer to online documents, our own and others.

Cheers,

- Art KD6O


On Mar 5, 2014, at 8:50 PM, Tony Langdon <vk...@gm...> wrote:

> On 6/03/2014 1:56 PM, Art Botterell wrote:
>> On Mar 5, 2014, at 5:09 PM, Tony Langdon <vk...@gm...> wrote:
>> 
>>> 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).
>> Not sure about those numbers.  If we were merely refactoring the existing hamlib codebase they might perforce be accurate, but I'll confess I was thinking somewhat bigger.  And even a single physical site often has more than one IP address space, particularly if there's a mix of wired and wireless networking.
> Most hams I know are lucky to have one computer in the shack, then a 
> healthy minority have a computer and a smartphone.  In my experience, 
> more than one LAN segment is not that common (for many years I was the 
> only ham I knew that ran this way, but have long since dropped it).  
> Also, routing between different sites is fraught with complications, 
> most common being IP address conflicts on both ends.
>> 
>> Anyway, this is why I started by throwing out a requirements draft for discussion.  Maybe I could encourage you to review and comment on that?  (I've sent an update to Nate for posting to SourceForge, rolling in some other recent inputs, but I think these issues arose even in the first version.
> How often are we going to refer to external documents?  For me this has 
> 2 issues:  one is technical - I am running on an underpowered laptop 
> with insufficient RAM, which makes swapping applications tedious, PDF 
> (which thankfully you've used so far) at least is (barely) tolerable, 
> due to the extra RAM required for Adobe reader. Other alternatives get 
> progressively worse.  The second issue is short term memory and 
> contextual recall, which is exacerbated by the slow task switching of 
> this laptop.  FOr this reason, I may rarely refer to external 
> documents.  It's far easier to respond inline to proposals written 
> directly into an email.
>> 
>>> 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).
>> Um... what devices are you running that can't support OpenVPN?
> Seems they've addressed this.  last time I had to look, only 
> desktop/server OSs were supported, but I see now that iOS and Android 
> are both supported these days.
>> 
>>> What effect will mandatory encryption and the encapsulation of all
>>> protocols into one data stream have on latency?
>> My experience has been that it's minimal compared with the other latencies involved in streaming.  But it's something we'd need to test.
> Yes, I'd test it.  There's also the concept of compromise.  On a LAN, 
> one can tweak for latency, on a WAN, security and bandwidth conservation 
> will be more important.
>> 
>>>  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?
>> The point of the VPN isn't so much the encryption... although anytime we implement user-based access control we do want some way to keep credentials private... but more that it creates a single shared address space where routing would otherwise be necessary.  Not sure whether IPv4 vs v6 is really an issue... and certainly v6 doesn't magically solve the routing problem.
> v6 will (eventually!) resolve some issues.  One big issue with NAT is 
> that most shacks will be running on one of a small number of network 
> segments - 192.168.0.x and 192.168.1.x are particularly popular.  Put 
> that on both ends of your tunnel and see how your routing goes. ;)  
> Bridging is an option but that becomes an issue too, you'd have to 
> selectively block DHCP broadcasts otherwise things get messy really 
> quickly! :)  Even without IPv6 infrastructure, tunneling IPv6 over v4 
> and having Stationserver completely v6 aware might resolve routing 
> issues.  There's a lot more v6 private address space (and some of us 
> like me already have public v6 addresses).
>> 
>>>  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).
>> Yes, I imagine we'd want to use it as-is rather than changing or incorporating any code.  So that might de-facto be the WAN module concept.  (Personally I'd prefer to see security the default and allow users to turn it off if they choose to.)  Not sure about compression... that also can have latency implications.
> Compression may be useful for some WAN links, particularly for mobile 
> users, who have latency and jitter issues anyway.
> 
> -- 
> 73 de Tony VK3JED/VK3IRL
> http://vkradio.com
>