Charles Brabham wrote: > What you describe can be done but it would be a step back, not forward from > Packet networking as we know it. - This assumes that you are talking about a > network that covers a significant area and has a good number of users in it. > Your idea would be most advantageous with a small number of users within a > small area. For something like that, you would be best off utilizing old WIFI > equipment, off of the ham bands. - And we all know how far the development > and utilization of ham radio WIFI went... When it was finally realized that > PART97 was not going to be repealed, allowing internet content to be > irresponsibly transported over the ham bands, all of the interest in ham > radio WIFI suddenly dried up and blew away. - R.I.P. hinternet. >
Ok, let's make it this way: 1. I did not mean of transporting any Internet-originated content by using the ham packet infrastructure. I meant of only ham packet traffic. 2. I know of many types of "official" node systems (incl. Flexnet, BPQ etc) but did not think about them because they ask for either better or separate dedicated computers (besides their end-users' packet operations). I thought about some implementation/modification of 'silent nodes' within the existing AX.25 protocol or, if you like it that way, existing modems/TNCs. I also said to allow some, say up to 10% of the usual TNC utilization to be used for node traffic. For example, if there are some 4-5 packeteers in a city area, whose technical conditions are different (antenna hight, output power, better listening to the other stations etc), why shouldn't be possible for a low-end station to use such a better "node" from the neighborhood - instead of a remote distant node? The steps would be the following: 1st: My 'low-end' station fires up and becomes active, including its own "node", 2nd: My 'low-end' "node" listens immediately what it can hear around (before me, as its operator, even think to transmit something), 3rd: My 'low-end' "node" recognizes the availability of the nearest "hardware node" on the hill, but also hears some other ham's 'high-end' station's "node" somewhere in the city, 4th: My 'low-end' "node" put both nodes in its node list, compares the quality of them and, as a result, decides to use my buddy's "node" rather than the hill's node - maybe just because my 'low-end' antenna better communicate with the buddy's station than to the hill's one 20 km far, 5th: When I am about to transmit something to the packet network, my station is already prepared for sending my packets through the buddy's "node" (*and from there* to the the hill's hardware node). In the same time, I suppose my 'low-end' station would avoid sending to many retries, which might happen if I forced it to use the hill's node only. 6th: My buddy's home "node" forwards information being received from me without problems because it communicate the hill's node better than my system (and his/her "node" spends up to 10% of it capacity for that, as mentioned earlier), 7th: During the conversation, if it happens that my buddy switches his/her system off (and goes to bed), my 'low-end' "node" recognizes that the buddy's "node" disappeared and immediately recomputes its node-quality list, 8th: My 'low-end' "node" recognizes that the only available node is the hardware one (on the hill top) and automatically switches to that one (maybe without giving any particular attention alert to me -related to that take-over being taking place). 9th: My 'low-end' "node" uses the hill's node with more or less retries (because, as mentioned, it hears the hill's node with different, probably lower quality compared with the buddy's "node" that had disappeared). 10th: Suddenly, the other ham in the city wakes up and activate his/her 'high-end' station which, in turn, hears the mountain node better than my station does. My 'low-end' "node" recognizes the change soon, recalculate its best route(s) and a network "take-over" takes place again, etc etc ... So, I wanted all of that to see within a TNC to work automatically - without installing/activating external node programs (BPQ, Flexnet or whatever). I mean, just to become a part of the protocol, or like. (I wouldn't mind if it could be manually switched on/off.) I don't see why such a system would not be viable for more than 1-2 station per area. In fact, what is a probability that, say, my 'low-end' "node" uses more than one buddy's "node" as a relay for reaching the 'real' hardware node on the hill or so. I suppose that my approach would work for a minority of 'low-end' packeteers who do not have something stronger than a handy talkie with a rubber ducky. I also suppose that the actual packet node networking, where a node serves its end-users equally (but where some of the low-end users can hardly reach the node), is more vulnerable to endless retries and waiting for answers, than the system I suggest. Maybe I am wrong, maybe not. Misko YT7MPB
