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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Just sketching some ideas... thought I'd share this and make sure I'm on the same page as everyone else... - Art

On 6/03/2014 9:57 AM, Art Botterell wrote:
> Just sketching some ideas... thought I'd share this and make sure I'm 
> on the same page as everyone else... - Art
Might be getting ahead of ourselves a bit.  OpenVPN?  Sounds rather 
specific for network links at this early stage.  And it might be 
overkill for 99% of installations.  For the other 1%, an add-on WAN 
security module might be better, even if that uses OpenVPN in the 
background.

Some form of encryption may be warranted, but the effect of that on 
latency, especially on lower powered platforms might need to be considered.

More a flagging it as a "To be considered"/"To be investigated", and not 
being technoiogy specific at this early stage.

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

Yes, maybe I should have called that out specifically, but I figured somebody would ask. ;-)  Like all the rest it's just a suggestion.

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.

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.  

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.

Thanks!

- Art KD6O

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

> On 6/03/2014 9:57 AM, Art Botterell wrote:
>> Just sketching some ideas... thought I'd share this and make sure I'm on the same page as everyone else... - Art
> Might be getting ahead of ourselves a bit.  OpenVPN?  Sounds rather specific for network links at this early stage.  And it might be overkill for 99% of installations.  For the other 1%, an add-on WAN security module might be better, even if that uses OpenVPN in the background.
> 
> Some form of encryption may be warranted, but the effect of that on latency, especially on lower powered platforms might need to be considered.
> 
> More a flagging it as a "To be considered"/"To be investigated", and not being technoiogy specific at this early stage.
> -- 
> 73 de Tony VK3JED/VK3IRL
> 
> http://vkradio.com

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

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.

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.)

> 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?

> 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.

>  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.

>  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.

- Art KD6O

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

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
> 

On 6/03/2014 4:56 PM, Art Botterell wrote:
> 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.
True, but I doubt many will go to the extent of multiple network 
segments.  I think the main thing is whatever we use will have to "just 
work" (aside from the obvious configuration of radios etc). The VPN may 
help with that (especially NAT traversal).
>
> 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.
True.  I'm used to running VPNs to link networks, not hosts.  In this 
case, linking hosts would make more sense.
>
> 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!
IPSec is on the router, the laptop doesn't need it.  IPv6 comes with 
Windows.  I did say I can open a PDF, just there is still a bit of 
overhead switching between that and email.
>
> 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.
At this point in time, "pretty cheap" is too expensive.  Hopefully that 
will resolve soon.  I eventually hope to fix the Macbook, which will 
solve the speed issues.  Right now, I'm just keeping what I have going, 
and that's about it.  And I still don't handle referring to large 
documents well, even when the technology is on my side, but that's a 
whole other story, all that can be done is we work with what we have the 
best we can. :)

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

As opposed to OpenVPN, how does an SSH tunnel compare?  I use SSH quite
a bit myself for remote access and with FUSE to provide a mount point.
It took a bit of fiddling to get working to my satisfaction initially
years ago but now I have the recipe so it's the first thing I do on a
new box I plan to admin.

In other words, is authentication/encryption necessary in Station
Server?  Could this be handled by a recommended "best practice" for
a OpenVPN/SSH tunnel by those interested in doing so?  I'd rather leave
security to those who understand it well (I don't understand it well at
a programming level).

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

On Mar 6, 2014, at 4:15 AM, Nate Bargmann <n0...@n0...> wrote:
> As opposed to OpenVPN, how does an SSH tunnel compare?  

SSH tunnels need to be set up individually, one for each data connection (the control and one or more content channels) and all they buy you is encryption.  They don't help with routing or firewall issues and don't bundle the complete network interface into a single identifiable network connection.  They also require that the remote user has at least some system-level privileges on the server.  As far as encryption strength goes they're comparable.

> In other words, is authentication/encryption necessary in Station
> Server?  Could this be handled by a recommended "best practice" for
> a OpenVPN/SSH tunnel by those interested in doing so?  

It could.  However, that gets back to an underlying requirement, the one for the ability to have multiple client connections with varying levels of privilege (read-only, read-write, admin, etc.)  That varying-levels bit implies being able to verify who's who, else the distinction is pointless... much simpler just to make every connection full-privilege.  

And if we're going to distinguish between sessions that means having some sort of shared-secret identity token... a password is the most common, although a shared key (certificate) also works... and it's never good practice to be passing such "secrets" around a network in the clear, even on a LAN.  (I'd point to pretty much any recent day's headlines for examples of what happens when security gets postponed or tossed onto the too-hard stack.)

The existing hamlib is a processor-centered design that does everything inside a single box.  If we want to move to a network-based client-server model we're going to need to learn some new tricks.  Otherwise, we're just refactoring the existing code... which may be a good exercise, albeit a less interesting one.

Anyway, this is a good discussion to be having, and I hope folks will read the requirements document and consider each point carefully, as that's really the stage where we want to define project scope so as not to spin our wheels further down the road.

> I'd rather leave
> security to those who understand it well (I don't understand it well at
> a programming level).

Yes, that's why I suggested an established, state-of-the-art package like OpenVPN rather than a "roll your own" approach.  It's a turnkey solution, no programming involved, and it's been refined and vetted over a number of years by actual security boffins.  I'd encourage folks to learn about it, if only as another tool in the toolkit.

But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.

- Art KD6O

* On 2014 06 Mar 09:51 -0600, Art Botterell wrote:
> But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.

Thanks Art.

I know a broached this subject again in my reply about the requirements
document so no need to rehash it all there again.  :-)

As I stated in that reply, I can be convinced for a good use case and
again, it's my inexperience showing, not opposition.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

On 7/03/2014 2:48 AM, Art Botterell wrote:
> It could.  However, that gets back to an underlying requirement, the one for the ability to have multiple client connections with varying levels of privilege (read-only, read-write, admin, etc.)  That varying-levels bit implies being able to verify who's who, else the distinction is pointless... much simpler just to make every connection full-privilege.
I agree here.  Stationserver is not intended to be multi user aware.  
It's for controlling a single station by a single person, so giving 
every connection full privilege makes perfect sense here. Multi user 
capabilities (validation, user auhentication, access control, etc) are 
best left to an optional remote base add-on.
> Yes, that's why I suggested an established, state-of-the-art package like OpenVPN rather than a "roll your own" approach.  It's a turnkey solution, no programming involved, and it's been refined and vetted over a number of years by actual security boffins.  I'd encourage folks to learn about it, if only as another tool in the toolkit.
It is a good package.  I used to use it for VPNs years ago, when I had a 
need for a true VPN - for connecting LAN segments together, as well as 
individual mobile users to the LAN.  The only reason I don't use it 
today is I have inbuilt IPSec support at both ends (router and mobile 
devices), and the router doesn't support OpenVPN - I'd have to install 
it on the one Linux netbook that runs 24x7.  So I am quite familiar with 
OpenVPN and would highly recommend it.
>
> But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.
Well, if we decide to go the mandatory OpenVPN route, we should have the 
Stationserver installer (1) make sure OpenVPN is installed and 
functional, and (2) configure it on the server and clients so it "just 
works" with minimal effort.  While OpenVPN is relatively easy to 
configure, networking tends to baffle most hams, so the more we can do 
for end users, the better.

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

On Mar 6, 2014, at 2:01 PM, Tony Langdon <vk...@gm...> wrote:
>  Stationserver is not intended to be multi user aware.  
> It's for controlling a single station by a single person, so giving 
> every connection full privilege makes perfect sense here. Multi user 
> capabilities (validation, user auhentication, access control, etc) are 
> best left to an optional remote base add-on.

Respectfully, Tony, Stationserver is intended to be whatever we decide it should be.  Each of us have personal preferences, but I'm not sure any of us should try to dictate.  This is a collaboration... at least I hope it is... and the requirements document is labeled "draft for discussion."

Of course you can write your own code any way you like.

Anyway, the multi-user requirement sprang from what I thought was your suggestion that different client connections should have different capabilities.  But we can certainly drop it if that's the consensus of the folks who speak up.

- Art KD6O

On 7/03/2014 9:17 AM, Art Botterell wrote:
> Respectfully, Tony, Stationserver is intended to be whatever we decide it should be.  Each of us have personal preferences, but I'm not sure any of us should try to dictate.  This is a collaboration... at least I hope it is... and the requirements document is labeled "draft for discussion."
I should have said a single user system was my original vision (as 
documented online late last year). :)
>
> Of course you can write your own code any way you like.
>
> Anyway, the multi-user requirement sprang from what I thought was your suggestion that different client connections should have different capabilities.  But we can certainly drop it if that's the consensus of the folks who speak up.
I I see where this came from.  My suggestion was that clients could have 
the ability to temporarily lock other connected clients out of changing 
radio settings, so they could perform critical operations (e.g. 
satellite antenna and Doppler tracking) without being interrupted by 
stray requests from another client.

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

On Mar 6, 2014, at 3:33 PM, Tony Langdon <vk...@gm...> wrote:
> I should have said a single user system was my original vision (as 
> documented online late last year). :)

Tony, I have no desire to vandalize your vision... but I didn't realize we were building this just for you!  So what do you need, exactly?

> I see where this came from.  My suggestion was that clients could have 
> the ability to temporarily lock other connected clients out of changing 
> radio settings, so they could perform critical operations (e.g. 
> satellite antenna and Doppler tracking) without being interrupted by 
> stray requests from another client.

Guess I'm not clear on why multiple clients would be interfering in a single-user system.  Is it possible we're really talking about a process priority issue?

- Art KD6O

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

Library to control radio transceivers and receivers

hamlib-stationserver