At 08:26 AM 3/10/2010, you wrote:
>1. Use a VPN network with multiple (failover) servers to connect to, >linked together, geographically spread out. This enables us to >create a private network on top of the internet or any other network >medium that can encapsulate the VPN. We think about using OpenVPN. The problem I have with a VPN or any form of tunneling where you have to connect to a fixed point first (as opposed to encapsulating packets as needed on specific links) is that you can easily end up with sub optimal routing (especially for those of us far from the core of the network). The setup time for OpenVPN is quite lengthy (in the order of 30 seconds in my experience), so to bring it up dynamically on a point to point basis would be rather slow. You need something that can encapsulate packets, but that can also send them _directly_ to the destination gateway over the Internet. Strong authentication is desirable, but I don't believe that it's necessary to bother with the overhead of encrypting the payload. Something like how IRLP does it (PGP authentication, audio in the clear), but faster and more flexible to deal with the unconnected nature of callsign routing or DD data movement. >2. Ip addresses. Every repeater gets a subnet inside the 10/8 >network, this can be organised as the 44/8 was. Maybe we can even >use the 44/8 instead of 10/8 to not interfere with existing networks >inside a 10/8 Yes, 10/8 is a problem here, for starters. And do we really need to worry about IP addresses (other than those on the Internet, of course) at the D-STAR level? IP addresses should be assigned to gateways on an as needed basis. Do we need to give each DD node an IP, or can the gateways have a DHCP server to dynamically assign IPs to local DD stations? >these are just our ideas. If you are serious about developing >something like you say, I think we best startup some sort of >workgroup and combine the best ideas. We really like the VPN idea as >it offers natural authentication that is proven to work. The >(open)VPN setup can be implemented in the software. Interesting ideas, certainly a lot of good ideas there. >Our preffered language would be Java. I see in your code snipped >that you prefer this too. >Let me (us) know what you think. Personally, I don't like Java, because I like to run lightweight systems, and the JRE can be a real memory hog. Java's performance these days is excellent, it's just that the memory footprint can get a bit large. Pity, because Java is one of the few modern languages that I've actually done any serious programming with. I also have a long term goal of running all my radio stuff (IRLP/Echolink/D-STAR etc) on embedded/low power boxes. This is both a cost saving measure, as well as doing a tiny bit for the environment. :) I also agree with everything being 100% command line. I run any server/infrastructure box without a GUI if I can. 73 de VK3JED / VK3IRL http://vkradio.com
