Standards

[to NEDA homepage]


Off of NEDA's home page there are sections about Networking standards regarding non-specific general purpose packet networking.  FlexNet has some features that allow other more specific networking features to be implemented: it's expandable application environment, multiple text files, and automatic route selection, for example.  This segment of the web is devoted to exploring and taking maximum advantage of those features.  
All of NEDA's standards are negotiable.  The organization insists that all of it's official publications support those standards.  The club could use your input.   We publish applicable ideas in the NEDA Quarterly.
Untitled-1.GIF (829 bytes)

Ideas

Backup paths

One of the features of FlexNet is that it will automatically choose the route that has the lowest latency.  This means that if there is an alternative path, however bad, it will eventually get chosen in place of an overloaded or failing link.  This gives excellent redundancy.  It is thus reasonable to put some redundant link in place.

It is important not to choose a redundant link that could be harmful to the community at large.  We don't use HF or 2m for backbone links.  It is reasonable, however, to run a series of 6m single port nodes on hilltops to serve as a backup path.  Then, if during an ice storm or power outage, one of the primary nodes along a major UHF linked backbone were to go off the air, the 6m path could be used instead.  Note that an HTS laden 1200 baud path would be SLOOOOWWW compared to using dedicated links. 

Untitled-1.GIF (829 bytes)

Text File Standardization

It is reasonable to have certain expectations about what kind of data will be present on the node for access by remote control.  Almost any user would be interested in knowing the city, state, mountain, and sponsor of a node.  You'd also want to know the frequencies that user ports would be on, and what servers are available.  It might also be nice to know how to connect to the sysop of the node for a live chat. 

Another good use for the data on the node is for network mapping.  The network mapper would like to know where the node is in a machine readable form, like with grid square/madenhead text (FN32ft  is where my QTH is).

I started a web section for an open discussion on this topic.  Check it out

 

Up Text Files

[to NEDA homepage]
Link to NEDA home page

Comments on these pages??